Subscribe to this thread
Home - General / All posts - M9 Basics
Ian
213 post(s)
#20-May-18 23:58

I am trying to migrate from M8 to M9 and keep getting stuck on the basics so due to time constraints go back to M8. I have imported image files and a shape file created a map dragged the image files into the map with no problems when I drag the drawing file in it doesn't show up. I have tried assigning projections first - but from my reading this isn't necessary. I have read the basics in the M9 manual and can't see where my problem is. Can someone point me in the right direction please?

Ian
213 post(s)
#21-May-18 00:30

If I assign projections to each of the image tiles then create a map and drag them into it they don't sit in the correct places. They over lap and sit behind one another?

Dimitri

5,119 post(s)
#21-May-18 05:51

Sounds like a projection problem. It is usually one of the following problems or a combination of them: 1) problem with the data, 2) not imported with the correct projection, 3) failure to assign or manage correct projection.

If you were to contact tech support they'd begin by gathering all necessary info, for example, what build of 9 you are using, what format you are importing, how you are importing, etc. The Contact Tech Support page has a useful checklist of good info.

It says that when you ask a question that question "should be specific and include complete and detailed information on anything you did from which the question arises. For example, if the question has to do with importing a particular file, state exactly how you have attempted to import that file including a step-by-step description of each command or dialog you have used and the settings employed in each such command or dialog."

So, begin by telling us what build of 9 you are using, what the files are from which you import and exactly how you are doing what you are doing, step by step. Don't leave anything out.

Consider also reading through relevant examples, like how to import a shapefile, the merge images example, the projections example like Detecting and Correcting a wrong projection, etc. Those pull together in one place various basic steps.

By the way, it helps to choose a descriptive thread caption. Your thread would better be captioned "possible projection problem"... if it really is a "basics" problem, describe what the specific basic issue is.

Ian
213 post(s)
#21-May-18 11:24

Thanks, that was helpful. I assumed it was a projection issue as the image layers in the map are miles away from the drawing layer. When I first read the basics of importing files I thought I didn't need to assign the projections but having done a bit more reading I see that was incorrect. I will try again from scratch. In M8 when importing files you chose the file type before importing and then only those type show up. M9 shows all the file types. If I want a drawing file - say a shp - do I just select that file and M9 will bring the other necessary files? Or do I highlight everything associated with the shp file? Likewise with a image file - say a jpeg - do I only select the actual jpeg and M9 will bring the rest?

Dimitri

5,119 post(s)
#21-May-18 11:53

If I want a drawing file - say a shp - do I just select that file and M9 will bring the other necessary files?

When all else fails:

Example: Import a Shapefile

Example: Import Shapefile and Create a Map

... should get you started. For questions on images, see

Projections

... and the various examples.

Ian
213 post(s)
#21-May-18 11:57

Yep. Went and did that after posting my reply. Thanks, thought I would have learnt by now...

Dimitri

5,119 post(s)
#21-May-18 12:11

There's also a video.

Ian
213 post(s)
#21-May-18 12:55

Have read and watch all those. Can create a map using the shp file but having issues with the image files. I have downloaded these in NZTM - same for the shp file. When I import the shp TM is the projection shown in black in the contents pane (I have tried this process by correcting the projection). The image files in red show psydo mercator, so I change these to NZTM which then show in black. However, when I create a map the image tiles all sit on top of each other and the shp file is miles away. This all works without a hitch in M8 so i assume I am doing something wrong in M9 to be having these issues. Can't see what it is. i'm sure I need to read something else but I can't see what it is

Dimitri

5,119 post(s)
#21-May-18 14:04

Yes, it sounds like you're doing something wrong, probably something very simple. Folks here in this forum can't advise you if you don't say exactly what you are doing. "I imported a file", for example, says zero. In contrast, "I imported a .tif file using the following dialog with these settings, and here is where you can download that file..." says something.

Likewise, "so I change these to NZTM" says nothing, since you don't say how you "changed" them or what settings you used.

If you provide more details on exactly what you are doing and, ideally, a link to sample data, then people here in the forum can offer specific advice.

---

The best, fastest way to learn 9 is to not skip the initial reading and then hop around trying to read only those things which you think you must. That takes far longer and guarantees lots of needless frustration. The best way is to read the topics in order starting with Read Me First, skip Changes and Additions, then Introduction then all of the topics in the Getting Started chapter and Basics chapter. After the first five or six topics in Basics you can start in reading Examples every now and then to take breaks from the straight reading of the Basics topics.

Watch the videos, too. There are over 60 of them, but they help to get your head around how to use the system.

adamw


8,259 post(s)
#22-May-18 09:48

If I want a drawing file - say a shp - do I just select that file and M9 will bring the other necessary files? Or do I highlight everything associated with the shp file? Likewise with a image file - say a jpeg - do I only select the actual jpeg and M9 will bring the rest?

With SHP, you select just the SHP file and 9 brings the rest.

With JPEG, you select just the JPEG file and 9 brings the rest.

Same for other files.

Regarding the projection - is it supplied via a PRJ for SHP and a PRJ for JPEG? You seem to be saying that 8 overlays SHP and JPEG correctly, but 9 does not. If so, that might be a bug in 9. Could you please contact tech support and report this, and send the data files (SHP + PRJ and JPEG + PRJ)? Here is how to report a potential bug.

You can also post the files here - possibly just the PRJ ones if the data is sensitive. This way others could verify what 9 does with them and how that's different from 8.

Ian
213 post(s)
#22-May-18 22:21

Have done the reading I should have before starting so have the import side sorted. I will set out how I did the import and see if I have done something wrong first then send on to tech if it looks like I haven't. Not sure if I can post the files here as the image files are quite big.

I downloaded some aerial image files (as Jpeg 2000 files) and a legal boundary file (as a shp file) from land information new zealand - something I do all the time - to my computer. These were all in NZTM projection. I then unzipped them, opened M9, File <import brouse to the shp file <open. Same for the JPEG2 files - though I changed all file types to JPEG2 files before selecting (I have tried it without doing that bit as well and it made no difference to the outcome). Once imported open each of the tiles by double clicking<Contents<assign initial projection (pysudo mercator was showing in red)<edit coordinate system<Standard tab<type New into box<select new zealand transverse mercator. I added this to favourites by editing favouraites and used it from the favourites list for the rest of the tiles. When I open the shp file and go to contents it has Transverse mercator in black - in manifold 8 this is the projection that is selected there too (under conic I think) - I change the projection the same way as above with the JPEG tiles using repair projection (though I have also tried leaving it with the TM projection as well). Right click in the project pane<create map<chose NZTM projection<drag each of the image tiles and the shp file into the map. Yesterday when I did this all of the image tile sat on top of each other and the shp file was miles away somewhere. I have downloaded the latest version of M9 this morning and done the process outlined above. Today two of the image tiles show up and are sitting next to each other correctly and the shp file sites over top of them as it should but the other four image tiles are no where to be seen. If I zoom to fit nothing shows up so I assume it is still a projection issue with the other image tiles.

As I said this works with no problem in M8.

Any thoughts?

Ian
213 post(s)
#23-May-18 00:29

I have deleted the image tiles from the project that didn't show up and re-imported them as above but instead of assigning the projection using NZTM from the favourites list I went into the edit coordinate system and selected from the standard tab list each time and it has worked fine. Could I have done something wrong when adding to the favourites list? Will look again but it seemed pretty straight forward

Ian
213 post(s)
#23-May-18 03:09

To add to projections favorites I went edit favorites, clicked on the star to add a new entry, browsed to NZTM, selected, OK. Then it shows up in the favorites list.

tjhb

8,410 post(s)
#23-May-18 03:14

Ian,

I think you have done everything correctly, and have found a design issue in the projection dialogs that would ideally need fixing.

Using Repair Initial Coordinate System > Edit Coordinate System gives a dialog where current metrics--units, local scales, local offsets--are preserved by default. (They can be adjusted if necessary, but the default is to leave them alone.) That's great, especially for images.

But using Repair Initial Coordinate System, then instead choosing a favourite coordinate system from the menu, does not preserve current metrics, or offer to. Instead it applies the favourite coordinate system exactly as it was saved. That's a problem for images.

Not a bug, but definitely a trap.

Great description of the procedure by the way. Easy to follow.

tjhb

8,410 post(s)
#23-May-18 03:50

Perhaps the most straightforward thing would be for a confirmation dialog to be shown, like “Do you want to override existing metrics with default values?”, whenever a favourite CS is chosen for a component which does not have the same metrics as the stored favourite. Yes, No, Cancel.

If the answer is No, pop open the usual Metrics dialog, initially populated with current values.

Dimitri

5,119 post(s)
#23-May-18 06:55

some aerial image files (as Jpeg 2000 files)

The above is the root cause of the problem, if the format used did not convey projection info. Using formats for images which do not convey projection information means you must specify that projection information manually. With images, providing correct projection info can involve nuances that are easy to get wrong, local scale and local offsets being classic examples. There are ways of rigging the GUI to facilitate getting it right, but such rigging to make it easier in one area can make it more difficult in others.

The best solution is to use formats which convey projection info. I've found GeoTIFF, for example, to be very useful. If the format does the work for you, everything just falls into place automatically with zero manual effort required and no risk of getting anything wrong.

I'm puzzled by:

As I said this works with no problem in M8

Does that mean when you import the JPEG 2000 format images into Manifold 8 they automatically have the correct projection, including all local offsets and other parameters, assigned? If 8 could do that with these jpeg2000 files, say, because there was some sort of world file supplied with each, but 9 could not, that's something to add to 9.

---

If the file formats used do not convey projection info then you have to specify that manually. In what follows, "projection" is used, as throughout Manifold, as a synonym for "coordinate system."

It is important to be precise when you use a name for a particular coordinate system. In an ideal world, a specific name that is used means one, and only one, coordinate system. Strictly speaking, if any of the parameters are different, including parameters such as local offsets, it is a different coordinate system. In an ideal world, you would say that all of your images were in "some form of NZTM" but would not say they all are in identically the same, the one, true "NZTM."

But we don't live in an ideal world, so people, understandably and logically, apply the convention of using a name like "NZTM" to refer to a family of different coordinate systems, each of which use different local offsets or other parameters. It may be imprecise to use "NZTM" to refer to all of them as if they were the same, but hey, that's how GIS has evolved and it is the lay of the land on which we party.

To roll along with that linguistic imprecision, it is best if the GUI is not rigorous but does what it thinks you should have meant when you choose "NZTM". In the case of applying whatever is a default value for the "NZTM" coordinate system in all respects, that is, instead of applying a logically precise set of numbers, it does what it thinks you should in all probability want it to do and it preserves current metrics.

In many cases, that's a sane and sensible thing to do, but like all such well-intended cutting of slack in real life, there comes a time when the GUI, in the course of trying to out-guess the casual way in which commands are given, might wrongly guess what you should have meant. For example, it is risky business to automatically preserve such metrics in a situation where one is assigning an initial coordinate system because the data was imported from a format which does not provide projection info. When you start out with a situation where you knowthat the projection info is missing, incomplete, or wrong, it is risky business to silently preserve any of what is there.

Another situation is when the user commands that a particular configuration of a coordinate system be saved as a Favorite. The presumption in that case is you know what you want and you have configured it a particular way because that is exactly what you want applied. You could have gone to a lot of effort to figure out those particular offsets, for example.

What Tim suggests is useful, of course, but it is part of the endless task, "how shall we guess around what the user has commanded if what has been commanded might be wrong?" The pending suggestion is to guess one way where they are now preserved by default but to raise a confirmation dialog when a Favorite is applied.

My own view is that I don't like silent preservation of existing metrics, and would prefer that a check box be there right from the beginning to do so. Check it by default, OK, so most situations will work as they do now. And then if that particular configuration is saved as a Favorite, the status of the check box is also part of that Favorite. But that's just my taste.

The bottom line is that if the format does not provide all projection info you have manual work to do. Different systems can guess around various possibilities to try to help minimize errors and to reduce workload, but the best way to eliminate errors and to reduce workload is to use interchange formats which precisely provide all coordinate system info.

Dimitri

5,119 post(s)
#23-May-18 09:06

Perhaps the most straightforward thing would be for a confirmation dialog to be shown, like “Do you want to override existing metrics with default values?”, whenever a favourite CS is chosen for a component which does not have the same metrics as the stored favourite. Yes, No, Cancel.

Forgot to mention: another reason why I prefer such choices be made right at the beginning, and not when a Favorite is being applied, is that a Favorite is supposed to be a one-click convenience.

A Favorite should not raise secondary dialogs, like "are you sure you want to override existing metrics?", or "are you sure the datum used is WGS84? Maybe it is different for this image," and so on.

For such fine tuning and confirmations, better to use the Edit Coordinate System choice, and reserve Favorites for being one-click conveniences.

Ian
213 post(s)
#23-May-18 22:13

Thanks Tim and Dimitri. I understand a bit more about how it works. I didn't realize that the favorites worked like that I assumed it was just provided a short cut to the full list. My question is, whats the point in having a favorites list if it doesn't work properly? I'm guessing it must work with most files but there are some it doesn't? Is easy enough to use the full list so will just do that. Is there somewhere in the manual that discusses the use of the favorites list?

I used to use GeoTiffs for image files but I found they were often to big and slowed everything down in M8 so I would convert them to ECWs. Tim has also mentioned the using them instead of JP2s. Will go back to these, does M9 handle these better - speed wise - then M8?

When I said it works no problem in M8 I meant I assign the projection and there is no issue as opposed to the problems with the favorites list.

One more question. With the shp file M9 lists Transverse Mercator in black as the projection without me doing anything. The projection is actually NZTM though so I repaired that. In M8 the projection it assigns when the file is imported is Standard<Cylindrical<TM, which I then change. I assume there is a reason they both do that but I thought that M9 only assigns the projection if the info is there with the file to do so? In which case why would it do that if the actual projection is NZTM?

Dimitri

5,119 post(s)
#24-May-18 07:08

My question is, whats the point in having a favorites list if it doesn't work properly?

It works perfectly. The favorites list allows you to save a coordinate system that you want to be re-applied. It does that exactly. There is a lot to unpack here...

The problem here is that the favorites list did exactly what you told it to do: it applied, precisely in all details, the coordinate system you told it to apply. That the local offsets you told it to apply to some images were incorrect for those images is a different issue, to be solved by education.

As I noted in my mini-essay, all parameters are part of the definition of a coordinate system. Every last danged one of them matters, including such settings that as a matter of routine users might not think of, such as the use of the wrong datum, not considering the use of local offsets in images and similar matters.

I agree that the use of local offsets as part of the coordinate system definition for an image is confusing to many people. I don't like it that coordinate systems have evolved to utilize such things. But they have evolved that way so it is something we all have to live with. It's not the only nuance that often leads to problems.

We are all used to just saying "Latitude / Longitude" or "Pseudo-Mercator" and such and thinking that is all there is to it. But that is not all there is to it, not even in more familiar cases.

For example, Lat/Lon using NAD27 datum is a different coordinate system than Lat/Lon using WGS84 datum. If at some point you deleted the factory default and then used Lat/Lon with NAD27 and defined that as a favorite, calling it Latitude / Longitude, the Favorites dialog would faithfully apply your version of Lat/Lon whenever you clicked on it. If you found that pixels were slightly off compared to those data sets that used Lat/Lon with the more typical WGS84 datum that wouldn't be a case of the Favorites dialog not working properly, it would be a case of the operator erroneously commanding the application of the wrong datum.

That the Favorites list gives you the ability to define, precisely, a coordinate system you want to be applied with the convenience of a single click is a very good thing. It is not a bad thing. Having that can save enormous amounts of time when you repeatedly must apply the same coordinate system.

In cases where such coordinate systems are intricate, or where a lot of effort went into figuring out what should be the correct local scale, local offset and other parameters, it really is a huge convenience to be able to count on the Favorites dialog to faithfully and precisely apply exactly those parameters that you so laboriously configured.

Favorites are like the "Save to Memory" button on a hand calculator. Whatever you put in there is what you get out. So, if you save the value of pi, as 3.1415926, to Memory that's what you get out. But if you make the mistake of thinking "Oh, all this math stuff would be easier if pi was an even 3" and so you saved 3 into the memory of your calculator, it's not the memory function of the calculator getting the value of pi wrong when it applies 3.000 for you from memory.

Is there somewhere in the manual that discusses the use of the favorites list?

Yes. See the Favorite Coordinate Systems topic.

Will go back to these, does M9 handle these better - speed wise - then M8?

9 is so fast there is little or no point using compressed formats like either JPEG2000 or ECW, both of which as used are lossy formats. They are faster in 8 and in other settings because they throw away information, reconstituting something on the fly that may look like the original (if you don't look too closely) but which is is not the original data. They're both absolutely terrible choices if you need to work with actual data.

Speed doesn't come into what format you use for interchange because once the data is in 9 it is in 9, not in ECW or JPEG2000 anymore, and 9 is faster than anything else. If you link data and leave the data in the external file, then with a product like 8 the speed difference matters. If you bring data into 9 you leave the stone age behind.

Don't make the mistake of approaching 9 as if it were 8. It is different. If GeoTIFFs slow everything down in 8, that has no bearing whatsoever on what makes sense in 9. With 9, the smart thing to do (as the user manual so faithfully and helpfully advises) is to import into 9 format and then always store your data in 9 format. You have a one-time import but then after that everything is super fast, with no lossiness like ECW or JPEG2000.

When I said it works no problem in M8 I meant I assign the projection and there is no issue as opposed to the problems with the favorites list.

It worked for you in 8 because you applied the correct procedure in 8. If you apply the correct procedure in 9 to assign the projection it works perfectly in 9 as well. It's not a big deal.

9 does provide facilities that are way better than 8 for dealing with coordinate system issues. That's a good thing, not a bad thing, even though having better facilities and more capabilities means that if you are unsure how to use them correctly there are more ways to get things wrong. Let me give two examples:

1. I absolutely love how everything in 9 is exposed in a table. It makes it super easy to do things like copy a coordinate system value from a component's record in the mfd_meta table and paste it into a different component's record, thus automatically assigning/repairing a coordinate system from one component to another. Using the select pane and the Transform pane I can replicate that correct value with a single click to assign/repair hundreds of components at once. Absolutely magical. But that all depends on my knowing when "one size does not fit all" and knowing that a specific coordinate system should not be proliferated as is to hundreds of other components. The same, very powerful, facility that is a life saver when used correctly is also a very powerful tool for creating chaos when used incorrectly.

2. Favorites are wonderful. Applying a desired coordinate system with a single click is totally super. It's also a great way to cause chaos for people who don't understand that Orthographic centered on Kansas is not going to work for a view of Beijing, or that you can't just willy-nilly apply the same State Plane projection that's right for Oregon to the state of Florida.

With the shp file M9 lists Transverse Mercator in black as the projection without me doing anything. The projection is actually NZTM though so I repaired that.

Different systems often use different names for exactly the same projection. If 9 imported a shapefile and showed the projection name in black as Transverse Mercator, it is almost certainly a bad idea to "repair" it. The system took info from a .prj or whatever and had good reason to think the projection had been specified by the format which was imported.

Keep in mind that "NZTM" means "New Zealand Transverse Mercator"... it's just Transverse Mercator with parameters that make sense for New Zealand.

In which case why would it do that if the actual projection is NZTM?

I focus on 9 and ignore the "they" since it is a terrible mistake to in any way try to understand 9 by reasoning by analogy with 8. Please get 8 out of your mind and focus on reading the extensive documentation and examples in 9.

9 uses whatever the source says the coordinate system should be. If your shapefile reports the projection as Transverse Mercator that's what 9 uses. 9 is far, far better than 8 at extracting projections from things like .prj, as there is considerably more experience that is baked into 9 for such things. 9 might be wrong, but the weight of experience indicates that 9 will be right far more often than 8, or, for that matter, than other systems.

---

I get the impression you've never sat down to learn 9 from basics, but instead are reasoning by analogy to 8 and hopping around various topics. That's a terribly inefficient way to learn 9.

It also leads to doubt and wasted effort, because when you do things wrong it is too easy to leap to the conclusion that "oh, 9 isn't doing this right." Remember the immortal advice from the Bug Reports page: "Few things are as effective at stopping the solutions process as deciding too early on that the problem must be a bug."

Especially during the learning process it is important to have faith that 9 is doing it right. 9 has far, far more experience than 8 at things like coordinate systems, and it has power to spare to make things easy that are painful in 8. Let that experience and power work for you and don't fight it. For example, use GeoTIFFs so projections get handled for you automatically.

When 9 reports something to you that is puzzling, start by trusting that 9 is telling you the truth and try to figure out why that is puzzling. For example, if 9 imports a shapefile and reports it as projection "A" but you "know" that it is projection "B", the question to ask yourself is not "why is 9 making an error?" but "hmmm.. why do I think I know this is in B? Might that be a mistake?" I can't tell you how often I've downloaded data from various government sites where the site says "this data is in...." projection and in fact it was in some other projection. It is extremely common for such errors to occur, for .prj files to be wrong and so on.

tjhb

8,410 post(s)
#24-May-18 08:26

Nice post Dimitri. There is a lot to unpack!

For now one comment.

I understand what you've said previously, which the post above also reflects, about a favourite CS being essentially exact and clearcut. No "are you sure you want to do what you just said". It's a very good argument.

So I would now advance the point that perhaps applying a favourite coordinate system should *never* include current metrics (at least, not local offsets and local scales; units are possibly in a different category).

Local offsets and local scales are very much ad hoc, belonging to a particular image (very seldom to a vector layer), sometimes to several co-located or related images, but that is no obstacle to this treatment (exactly because any ad hoc values would be preserved). These should not, in my view, be saved as part of a favourite CS, and should never be applied with one.

On the whole I think that that would minimise potential confusion, as far as it is possible to do so.

Some potential for confusion would nevertheless remain, as (I agree) it should.

tjhb

8,410 post(s)
#24-May-18 08:53

I think I obscured this basic point by editing: applying a favourite CS should never overwrite non-zero local offsets or non-unit local scales with zeroes and ones. It should leave existing metrics as they are. (Units of measure being perhaps a separate category; not expressing a view.)

Dimitri

5,119 post(s)
#24-May-18 09:11

I think I obscured this basic point by editing: applying a favourite CS should never overwrite non-zero local offsets or non-unit local scales with zeroes and ones. It should leave existing metrics as they are.

I agree, except if those are explicitly specified in the Favorite.

Local offsets and local scales are very much ad hoc,

Also agree.

These are knotty problems where there are no clean solutions, only some approaches that may be better than others where the collective experience of the community can help guide any tinkering to make workflow easier and more reliable.

The root of all these problems is that how images are stored and then used within coordinate systems is a total hodge podge mess accumulated over time, with many different GIS systems over the last 40 or 50 years doing it differently. It's not even just the local offsets or local scales but also things like whether a pixel is "at" the lower left corner, the center of the pixel or whatever.

I understand the impulse to try to bring order by modularizing coordinate system definitions, for example, like saying "It's Lat/Lon" while allowing a choice of datums. But that leads to people thinking of just the top level thing without realizing all the details have to be in there. That's part of the lay of the land, one reason why the coordinate system dialog has three tabs, Standard, EPSG, and Custom.

Maybe one approach is that whatever you define as a Favorite applies only those parameters specified in the JSON string that defines the Favorite. For example, if it doesn't mention a datum, whatever is the currently assumed datum stays. If it says something about local scales or offsets, what it says should be used, otherwise they should not be touched. I haven't thought this through into the more intricate coordinate systems so maybe that's not a realistic approach.

tjhb

8,410 post(s)
#24-May-18 09:40

“I agree, except if those are explicitly specified in the Favorite.”

If they were, then in principle, yes.

But I think it should not be possible to save those parms as part of a favourite CS, because they are inherently ad hoc.

Being able to save a CS with ad hoc metrics adds nothing (except confusion later) over saving a CS without.

In any case, when a favourite CS is applied, ad hoc metrics already associated with the data should always be preserved.

Ian
213 post(s)
#24-May-18 22:10

Thanks to both of you for taking the time to explain all of this. You're right Dimitri regarding my lack of time learning M9. I have started reading through the topics you listed earlier, will make sure I keep reading past that.

Few more questions;

From the discussions above - and I hope I haven't got this wrong - but the CS saved to the favorites list for a particular image tile has exact information for that tile and not just a general projection information that can be applied to any tile? And if that is the case you would only use the favorites list if you wanted another layer to have exactly the same info. Which would explain why my image tiles all sat on top of each other?

Just to clarify the point about trusting M9 with projections. If it shows up in black that's what it is, don't change it to what you think it is - or is supposed to be?

I have read the projection stuff in the manual and I want to make sure I have this correct as well. In M8 I make sure I have every component in a map in the same projection and not leave things to on the fly calculations. With M9 I don't need to do this? In the example I have been dealing with having the image tiles in NZTM and the drawing layer in TM isn't a problem? The map will be in the projection of the layer I drag in first or the projection I specify.

One last quick question, M9 is going to replace M8 and is much better so best to migrate to M9 or will they both run side by side and are suited for different things?

Thanks

Ian
213 post(s)
#24-May-18 22:45

I have just read the map projection info and it says to have the largest components in the map in the same projection as the map. Is it worth reprojecting the smaller components so they are in the same projection or is it unnecessary?

I have also read quite a bit of the info on using the favorites list and it doesn't indicate the possibility of the issues I have had. From my reading it I get the message I had originally that its a quick way of assigning a commonly used projection - in my mind just saves going to through the extra steps and dialogue boxes, is a short cut to the projection info in the list. If that is not the case what is the difference with how M9 works between assigning the initial projection by going through to the standard tab and choosing the same projection from the favorites list? If it is that the favorites list projection has info particular to the tile I first assigned it to then shouldn't that be mentioned in the manual? But I suspect I'm missing something here

tjhb

8,410 post(s)
#25-May-18 00:46

Ian,

the CS saved to the favorites list for a particular image tile has exact information for that tile and not just a general projection information that can be applied to any tile? And if that is the case you would only use the favorites list if you wanted another layer to have exactly the same info. Which would explain why my image tiles all sat on top of each other?

Yes, yes, and probably yes.

Say I import an image, open it, then in Content > Component, I click the coordinate system icon (map calipers) then choose "Repair initial coordinate system" and finally "Edit Favorites".

Now the current projection of this image is listed in the lower panel of the window. I press "Add to Favorites" and the new favourite projection is added to the panel above (highlighted in red), with its parameters (in JSON string format) shown in the grey panel in the middle.

Amongst the parameters, I can see the "metrics" specific to this image (assuming that Manifold was able to read them from metadata during import). These are LocalOffsetX, LocalOffsetY, LocalScaleX and LocalScaleY. Local offsets specify where to anchor the lower left pixel of this image with respect to the origin of the CS. Local scales define the pixel size.

Pixel size is shared by all images having the same resolution. But the position of the lower left pixel is shared only if images (should) coincide or overlap.

Why save a favourite coordinate system that includes values so specific to one image? I can't think of a good reason. If I apply this "favourite" CS to a different image, then usually that image will be located incorrectly--unless the images happen to share exactly the same resolution, location and extent.

Ian
213 post(s)
#25-May-18 01:36

Thanks Tim, thought maybe I had missed something in all of the dialogue, or it was simply my lack of knowledge. Am interested as to the reasoning behind being so specific. Does it have more application/use with other file types other than images? And is this only an issue with certain types of image files?

tjhb

8,410 post(s)
#25-May-18 02:09

That's a good question. A good exercise to try to explain it.

First take vector data, a drawing. That is stored as a collection of vertices. For points, that's all. For lines and areas there are also relations between vertices, mainly their grouping and sequence (sometimes also curves).

Each vertex is just a pair of floating-point numbers XY (or XYZ for 3D vertices).

Those values are locations in the coordinate system, X and Y distances from the origin of the projection at (0, 0). That is complete and unambiguous, nothing else required.

Images are different. What is stored is not locations in the coordinate system at all, but for each pixel, its location within the grid of the image along with a pixel value. The bottom left pixel of each image is always at (0, 0). X and Y are just sequential indexes inside this specific image. (That is what makes images efficient for storing dense, regular data.)

To show the image in the right place in the world (in the current coordinate system), more information is needed. We need to know where its bottom left pixel should go, and the size of each pixel. That's the case for all images.

The coordinate system for each image must be specific, because image data is inherently generic.

tjhb

8,410 post(s)
#25-May-18 01:25

[Above I was lazily using "projection" to mean "coordinate system". The projection is only one part of the CS.]


About seeing just "Transverse Mercator" after import, when you know that the data is in NZTM:

This is often due to a limitation of the data format, e.g. GeoTIFF.

What matters is the projection type, datum (~base CS), the parameters, and for images also the "metrics" (local offsets and scales).

If those are all correct, then the name doesn't matter much at all--unless it matters for reassurance or standardisation, or if you are passing the data to someone who expects to see it.

In that case, how to "correct" an initial CS generically named "Transverse Mercator" (but otherwise fully correct) to show as "New Zealand Transverse Mercator"?

For vector data, just do it. Metrics don't apply (well, hardly ever), so you can just use "Repair initial coordinate system" and choose standard NZTM.

For images, care is required, because we do need the metrics (otherwise the image will be in the wrong place) but standard CS definitions do not include them.

There are many ways to do this, and it doesn't matter which way you choose, but there are three basic steps: record the initial metrics after import, change the projection to the standard one, then adjust it to use the initial metrics.

Recording the initial metrics can be a case of copying part of the JSON text ( "LocalOffsetX": ..., "LocalOffsetY": ..., "LocalScaleX": ..., "LocalScaleY": ...) from Manifold metadata--which can later be restored by pasting (inserting). Or you can write them down (riskier) and reset them manually throught the Metrics dialog.

Dimitri

5,119 post(s)
#25-May-18 07:05

Just to clarify the point about trusting M9 with projections. If it shows up in black that's what it is, don't change it to what you think it is - or is supposed to be?

Yes. When 9 reports the coordinate system in black font it has reason to believe that coordinate system has been correctly assigned.

It is true there are cases where such "reason to believe" is incorrect. A classic example is when somebody publishes a shapefile with a .prj taken from some other shapefile, so what the .prj says is wrong. 9 has no way to know that the shapefile ensemble that was imported contains an error... it just trusts that the .prj is telling the truth. Even files from respected, national cartographic bureaus such as IGN in France or USGS in the US might have such errors. It's rare, but it happens.

Another classic example of such errors are people who create drawings from geocoded tables where the coordinates in the table were acquired before WGS84 became popular. The most common thing in the world is for people to blindly apply Latitude / Longitude projection using WGS84. So, they fire up their GIS and save a shapefile in lat/lon WGS84, and they publish that. But that's a mistake if they read those coordinates from a detailed map in lat/lon that used NAD27, not WGS84.

In both the above cases "repair" must be used to correct the data. Note, however, that the error is in the data itself: 9 accurately read and applied what the format said to use.

It's always possible, of course, that a new bug might be found in 9 where the format is correct but for whatever reason 9 did not read the coordinate system correctly. But that's not the place to start when figuring out a puzzling situation. Start by assuming the coordinate system reported in black is correct.

In M8 I make sure I have every component in a map in the same projection and not leave things to on the fly calculations. With M9 I don't need to do this?

Correct, so long as the projections you use are not totally incompatible for the region of interest. 9 reprojects on the fly so fast I no longer bother to reproject layers in advance into the same projection, at least not as a matter of speed. Instead, the only reason I now use the same projection in a map as an image layer is when I don't want an imageserver layer like Google or Bing to be distorted by reprojection on the fly. Using the same projection ensures that labels and other text remain nice and neat as originally intended. You can see the effect in this topic, an essential topic to read.

In the example I have been dealing with having the image tiles in NZTM and the drawing layer in TM isn't a problem?

If the Transverse Mercator you are using is compatible with the TM in the NZTM, no problem. If the Transverse Mercator projection you are using is totally incompatible with NZTM, then you'll have a problem. TM projections tend to be good only for highly specific areas of interest. Try to use them elsewhere and the mathematics explodes. Example: a TM centered on Kansas is useless for showing Beijing.

The map will be in the projection of the layer I drag in first or the projection I specify.

Yes. Exactly correct.

M9 is going to replace M8 and is much better so best to migrate to M9 or will they both run side by side and are suited for different things?

There is a useful discussion on that in the FAQ page for 9.

Depending on what you are doing, 9 has already replaced 8. In my personal use of GIS I think it may be a year since I've last used 8. 9 is so much faster at bigger images and vectors, and 9 is so much better at projections, using web servers, importing from zillions of formats, and so much more reliable there's no comparison for me.

The only reason to use 8 now is that 8 has benefited from about ten years of accumulation of gadgets from prior versions of Manifold. There are endless features within 8 - thousands of them - that accumulated over the years. If you have become accustomed to using such features, for example, viewbots, in 8 then learning how to do something different in 9 may not be to your liking.

The core problem with 8 is two-fold: first, it doesn't have the technology to handle larger data. 8 made the trade-off, as all of the classic GIS's did, to go for features that could be used within the data sizes typical back in the day, and not to try to build an engine that would work with the data sizes that are now emerging.

The second issue is that for all of the elegance and power of 8 the internal structure is an ad hoc structure that evolved over the years. It is not totally Rube Goldberg the way certain other classic GIS products are, but it is sufficiently ad hoc so that after a while you really cannot add more features to it in a way that is either reliable or maintainable.

9 deals with both issues by creating a new, hyper-modern structure that is designed to handle immensely large data, is fully parallel, and is easily extended in a highly consistent way. You can add features to it all day long in a very easy, totally reliable and highly maintainable way, and you could probably do that and continue to evolve the thing for the next 50 years.

That's one reason why as new conveniences get added to 9, often as folks who are used to similar things in 8 request them, the response after the initial "wow! that's faster than 8!" is "wow! that's so much cleaner and better than 8!"

There's a quote that appears on the forum from time to time from Henry Ford, where he commented that if in the beginning he asked what people wanted they would have said "a faster horse." That's a mistake to not make in connection with a transition from 8 to 9. Thinking "I want 8, just faster with bigger data" is a huge missed opportunity, because what you want isn't a faster horse, you really want a wonderful flying car that can take you from New York to London in an hour while you browse Internet, talk to friends worldwide, and are entertained by every movie ever made on your way.

The key way to approach this is first to learn 9 well so you understand what it can do today and how to leverage that effectively. Many people who do that will, right now, never go back to 8. But if after learning 9 you discover there is something you really need that is in 8 but is not in 9, speak up. Other people are doing that so when you see the various things that get added to 9 those are coming in priority order based on - I'll avoid the "if you don't vote your voice doesn't count" speech usually delivered at this point - Suggestions.

Over time, the need for anybody to reach for 8 to get something that they need which cannot easily be done in 9 will go away. Until then, if you need something in 8, use 8 and 9 side by side.

Ian
213 post(s)
#25-May-18 12:31

I really appreciate the time you have spent explaining this stuff and answering my questions. I have been going through the forum and looking at what some of the other users have been doing and reading what they have been saying. A lot of it is well beyond my use and gis knowledge but I have seen plenty that I would like to master and will be really useful for me. I'll get on with the reading and using 9 and put the time in rather than making a half arsed effort at it. Thanks again

Ian
213 post(s)
#30-May-18 03:55

i have just been using M9 to start a project so imported imagery and shp files as per the manual. When I open the image file - a Tif - the contents tab shows in black that it is WGS 84/pseudo mercator. As per Dimitri's instructions I should trust this is correct. I had downloaded it in NZTM - or so I thought. The shp file shows projection, in black as Transverse mercator, again I trust M9. I create a map using the projection the same as the image then b=drag the image file and then the shp file into the map. They are miles apart somewhere indicating a projection issue. i go back and repair the imagery projection to NZTM and everything works fine. I also tried re-importing and leaving the image as the projection M9 assigned and changing the shp file projection, this yielded the same result as the first try. This doesn't instill a lot of confidence in M9 assigning the correct projection. From Dimitri's comments this is unusual, can anyone suggest why I'm having this issue?

Dimitri

5,119 post(s)
#30-May-18 06:09

i have just been using M9 to start a project so imported imagery and shp files as per the manual. When I open the image file - a Tif - the contents tab shows in black that it is WGS 84/pseudo mercator. As per Dimitri's instructions I should trust this is correct. I had downloaded it in NZTM - or so I thought.

There is much to consider in the above, but we cannot consider the details without knowing the details.

Saying "as per the manual" doesn't provide details. After all, everybody thinks they are doing it as per the manual, right? :-)

Likewise, saying it is a "Tif" doesn't tell us what, exactly it is. "Tif" is a generic word that covers very many formats. A "tif" file accompanied by a world file is a very different deal than a GeoTiff. Which is it? How was the "tif" file created? Is there a sample?

When I open the image file - a Tif - the contents tab shows in black that it is WGS 84/pseudo mercator.

If you used File - Import and double-clicked on a .tif file to import it, a new image appeared in the Project pane, and then the very next thing you did was to double-click on that image file to open it and the Component panel in the Contents pane reported it in black text as Pseudo Mercator, then 9 had reason to believe that the file which was imported had declared itself to be in Pseudo Mercator. It doesn't make that stuff up.

Note the specificity of the description of steps in the paragraph above. It is written exactly that way to make clear that nothing at all happened except the import, it says how the import happened, and it makes clear that the image itself was double-clicked open into an image window with no other layers involved. Saying it that way eliminates the possibility that when somebody says the image was in PM what really happened is that they dragged and dropped the image into a map that was in PM and then they misinterpreted what the contents pane reported about the map being in PM (had the wrong map layer active), thinking that meant the image.

There are many things that could be done to take a closer look at why 9 thinks it was told that file uses Pseudo Mercator. I, personally, think it is not just a waste of time but also an irresponsible thing to do to guess with insufficient information. Why is that irresponsible? Because it misses an opportunity to teach people that paying attention to detail when reporting a problem is important.

Example: Saying "I imported a tif" is insufficient detail. Saying "I imported a file with a .tif extension that was accompanied by a world file with a .tfw extension that contained the following text <text here>. There were no other files in the folder from which I imported that .tif." .... that's good detail. Why is it important to note if other files were in that folder? Suppose there was stuff left over from previous import attempts that took priority over the .tfw... that matters.

So, please tell us more detail. Also, try creating a map that you know is in Pseudo Mercator. Create a default data source using the Favorites that is Bing streets. Create a new map and drag and drop that Bing layer into it first. Now you know for sure the map is in PM. Drag and drop the "PM" image you imported from the TIF into that map. Does it appear correctly overlaid on the Bing layer?

This doesn't instill a lot of confidence in M9 assigning the correct projection.

I've imported thousands of rasters and vectors. Hands down, 9 is way more reliable than, say, 8, at assigning the correct projection. It's so much better there is no comparison, and that's considering that 8 is very good at such things.

What I have noticed is that the better a system is at importing with genuine respect whatever a particular format claims for a projection, the more one notices problems of detail that a less-respectful system doesn't notice. These seem to fall into three categories, the first two of which are related:

1a. Outright errors when files are published. You visit the website for the national cartographic bureau of the Republic of Yooshkar-Oops and download the street map for their newly-renovated capital of Gazoombiga. The website claims all TIF files are provided in YOTM projection (Yooshkar-Oops Trans Mercator) but when the files are downloaded 9 reports them in Latitude / Longitude, in black. Why? Because the "world" file attached to the TIF file in the download said the image was in Latitude / Longitude. The problem came when an intern hired for summer work made a mistake copying files onto the Republic's web servers.

1b. Systematic errors induced by slacker idiocy. Satan's minions are working overtime. They've read the That YX Thing essay, chuckle to themselves while thinking "Yep... that's our thing!" and are cheerfully publishing data that states - right there in black and white - that the coordinate system is in Y, X axis ordering but in reality the data is provided in X, Y axis order.

2. Publication of partial coordinate system data in a way that assumes the only possible GIS package that might be used is the one the author used. The quirks just happen to line up for the author, but are insufficient or misleading for packages which can correctly handle details like local scale and offsets. This is a classic problem with images: when a format declares a given projection with zero offsets, but some local offsets are in fact required, the image can look OK and it seems that a projection has indeed been assigned by the format, but in fact what has been assigned by the format needs to be corrected.

In all of those thousands of imports I've noticed that errors in 9 resulting in inaccurate extraction of coordinate system info from a format have become extremely rare in the last, say, six months. Before that they were fairly common, hitting an error perhaps twice a week. That's not so bad when you consider the hundreds (counting all subtypes) of formats 9 can read and the many thousands of coordinate system variations encountered, but in the last six months such errors have become fairly rare. Considering all formats, including the exotic ones, it's probably down to once per month and for the more robust, well-understood formats I think it's been seven or eight months since any error, out of many thousands of files imported, has been seen.

Considering that such errors do pop up from time to time, it is important to use the latest build in case an error has been found and corrected. It's also worth keeping in mind that a new error might have been found.

The problem with that last sentence is that the moment you write it, there are people who will leap to that conclusion with every problem, especially beginners. That makes sense given the way human psychology works, and in many ways it is a tragedy that, in truth, there really are occasions where the first time a person plays the lottery they win. Dostoevsky remarked that the worst thing that can happen to somebody in gambling is that the very first time they ever visit the casino they win big. That can hook them and they spend the rest of their lives trying to repeat what is statistically almost impossible.

It is true that sometimes the very first time somebody who uses 9 will step on a previously unknown bug importing a coordinate system. But given that effects 1a, 1b and 2 above, together with the usual very many ways workflow might be done incorrectly, are by about a thousand to one margin more likely, that's not the first place to start any debugging.

The first place to start is to very carefully describe every detail of the files that were imported and exactly how they were imported, and every detail of the work flow that was done up to the point where an error seems to appear.

I can't tell you how many times somebody has said "Oh, I imported this following the manual and the import was wrong." When you ask "What did you do?" it turns out they imported it using "assign" and assigned the wrong system. Or, they did something like import a TIF file but not a GeoTIF. Instead, they just imported a TIF file and, not having a world file for that specific TIF they used a world file they found on the source website somewhere. Stuff like that happens all the time. If you don't know all details, you don't know what was done.

If it is a repeatable issue, by all means file a bug report, offering to upload a sample. Everybody knows that most bug reports are not bugs. That's perfectly OK, because reviewing many reports which are not bugs is exactly the routine way in which new bugs can are found.

tjhb

8,410 post(s)
#30-May-18 06:50

Dimitri,

That post is too long.

Literally no one will read it all.

Maybe only idiots will read the most important things. Who knows?

Why not write something shorter?

Tim

Dimitri

5,119 post(s)
#30-May-18 07:29

Why not write something shorter?

Because writing something like "without details nobody can identify the problem - tell us details" doesn't teach anything. That's especially the case when someone thinks they've provided details.

Look, there are two schools of thought when teaching somebody something new that requires attention to detail. One is to start by assuming the student has too short an attention span to learn what's required. If that's true, the problem cannot be fixed by reducing the learning to fit the attention span by removing necessary info.

The other approach is to acknowledge that, yes, some people do not have the attention span to acquire the knowledge they seek. That's life. I don't write for those people. Instead, I write for those people who value insights and who understand that a fuller discussion can help transmit knowledge. I start by giving people the respect that they can benefit from a richer discussion.

Plus, experience shows that the twit culture is not an efficient way to master significant arts. It only seems shorter to nibble at knowledge one twit at a time. "Is that it?" "No, it's different." "Maybe this?" "No, not that either." In the long run that takes much longer than investing into richer discussion at the beginning.

But... if you think differently about that, have at it!

As always, of course, anybody who doesn't feel up to reading my essays... no problem. :-) Don't read them.

Dimitri

5,119 post(s)
#30-May-18 08:11

Why not write something shorter?

Ah... re-reading my reply I see I missed an opportunity for a much shorter answer:

Why not write something shorter? "If you give a man a fish you feed him for one day, but if you teach him how to fish you feed him for the rest of his life."

So, I'll make you a deal: When questions come up, you take on the role of solving the problem in a sentence or two. That will provide a fish right then and there. I'll take on the role of patiently writing at greater length, including, of course, references to Dostoevsky and Satan as all good education should include. That may help those who want to fish for themselves. People who read the forum can then use either or both approaches as they see fit.

Ian
213 post(s)
#30-May-18 22:27

I was trying to save time by not relisting how I imported the file again, did the same as in a previous post, but here it is:

I downloaded a tif file and a shp file from Land Info NZ both in NZTM, they were saved as a zip file<unzipped<open M9<file<import < locate tif file < double click on it - there are also 2x xml files a TFW, text document and a aux file in the folder also<file<import<locate shp file<double click<in M9 double click on image file<contents< projection described as previously listed in black<back to project<double click shp file<contents<projection displayed as TM in black<back to project<create map<accept PM projection<double click to open map<drag image file into map<drag shp file into map

Projection info is incorrect as files don't line up so click on image file<contents<repair prjection<standard tab<chose NZTM<image and shp file now line up in the map

In M8 I never trusted the projection it assigned I always went and assigned the project myself. In M9 my very short bit of experience suggests I need to do the same but it seems I may have just hit that casino win instead.

I can attached the files associated with the tif file if they are of any use

Ian
213 post(s)
#30-May-18 22:59

I have attached a screen shot of both M8 and M9 using the same imagery and the same shp file (that I have been referring to above). M8 is much better in that the shp file sits really close to the actual boundaries in the image file where as M9 is quite off set. I'm guessing this has something to do with the projection issues I'm experiencing? In M8 the process was:

File<import image<select tif as file type<locate file<double click to import<file (file type shp already chosen <import drawing<locate file<double click to import<double click to open image<click on warning at top to chose projection<chose NZTM from national grids<double click drawing<edit assign initial projection (is in TM)<chose NZTM from natioanl grid<create map<tick both layers in dialogue box to include in map<double click to open map.

Another interesting - or frustrating point is that zooming in and out in M9 is slower that in M8. I thought it should be the other way around? Zooming in with the mouse M9 takes time to focus the image, is blurry for a while. When zooming out with the mouse I get a small rectangle of the image in the center of the project (shp file is still visible) then the rest of the image fills in. I thought M9 was meant to be much quicker than M8?

Attachments:
M8 capture.JPG
M9 Capture.JPG

Dimitri

5,119 post(s)
#31-May-18 06:38

Another interesting - or frustrating point is that zooming in and out in M9 is slower that in M8. I thought it should be the other way around?

9 generally is dramatically, overwhelmingly faster than 8, even if 9 is reprojecting very big raster layers on the fly.

Take a look at the video showing panning and zooming in 110 GB of images at once, at https://www.youtube.com/watch?v=Gvib5LqqE2o

That's a real video, no fake. You'd be waiting all week to open 110 GB of images in 8, and every pan / zoom would take many minutes.

It's true that 9 cannot work miracles. If you have a very large vector file (or a very large raster) and you try to open it on your 4 GB 32-bit notebook computer, it's going to be much slower than if you have enough RAM and so on for Windows to not thrash itself to death. But even so in such cases 9 will be far faster than 8. I don't of any case where it isn't, so if there really is a repeatable case where it is, that would be something to report.

It is, of course, important to do an apples to apples comparison. That can be deceptive sometimes precisely because 9's speed often causes people to overlook factors, like re-projecting on the fly, which cannot be overlooked in 8 because overlooking them in 8 causes everything to stop. So, in 9 it's fairly routine to have a map with many layers, big layers, where they are all in different projections, and you also have an imageserver layer in a different projection, and they're all being re-projected on the fly into the map's projection and it all works just fine.

In 8 you couldn't do that, for example, there's no having an imageserver layer *at all* in a map that uses a different projection, no re-projection of ECWs, etc., and in many cases if you didn't have a big image layer and a big vector layer in identically the same projection it would grind to a halt. So people set all that up in 8 with identically the same coordinate system for everything, and thus no re-projection on the fly, and then they wonder... well, 9 is faster but it's not, like, instantaneous the way I expected.

Like I say, look at that video and then try to open 110 GB of images in 8, and then report back whether 9 or 8 seem faster. :-)

adamw


8,259 post(s)
#31-May-18 09:40

Zooming in 9 should be same or faster than in 8 (with big data, much faster).

If zooming in 9 seems noticeably slower than in 8 on some data, we can certainly investigate that. Please report it to tech support. They will ask for the data and provide FTP space if needed.

Dimitri

5,119 post(s)
#31-May-18 06:27

I downloaded a tif file

What is the .tif file supposed to be? Is it supposed to be a GeoTiff? Land Info NZ is usually pretty good about describing their files.

there are also 2x xml files a TFW, text document and a aux file in the folder

What are those files? Note from the Getting Started topic...

Some file formats utilize accessory files such as "world" files, or .PRJ files to convey coordinate information for formats, such as shapefiles, which do not automatically convey coordinate system information. When reading formats Manifold will automatically read coordinate system information from accompany files, if they exist, in the following order: "world" files, .PRJ files, .XML files (Manifold System 8.00 accessory file) and .MAPMETA files (Manifold accessory files). In the event of conflicting coordinate definitions the last read file wins, since the read order is in order of more rigorous definitions.

If any of the accessory files claim to provide projection info, that is a possible source of error if they conflict or do so in ambiguous ways

it seems I may have just hit that casino win instead.

I can attached the files associated with the tif file if they are of any use

Could be you got lucky. :-) It could be a bug in the accessory files, in 9, whatever. If the file is supposed to be a GeoTIFF, try moving all accessory files of any kind to a different folder and then just import the .tif, and see what happens.

A useful debugging step is also to try importing it through GDAL. 9 is usually better than GDAL but sometimes GDAL will decode correctly that 9 does not. Sometimes that works due to an error in GDAL which cancels out a symmetric error that happened when the file was creating (as discussed in That XY Thing), but sometimes that happens because GDAL does something correctly where there is a bug in 9.

I've had much better experience with 9 and projections than 8. What would be most useful would be a link to the file you downloaded. Then we could get the TIF and whatever was downloaded as part of the zip as well.

adamw


8,259 post(s)
#31-May-18 09:34

Can you post a link to the files or report the issue to tech support and offer to send the files to them?

If you already did so, thank you.

dchall8
522 post(s)
#30-May-18 14:31

I'm guessing you've been waiting for years to say that.

There have been times when both of you answered one of my questions. Tim's was usually a one-sentence solution that gave a lot of immediate gratification. Dimitri's reply was, shall we say, enriched with additional information including the obligatory admonitions for not reading the 8,000 page manual, from front to back, before asking the question. Still his fishing parable, posted previous to this, has some merit.

adamw


8,259 post(s)
#30-May-18 10:20

i have just been using M9 to start a project so imported imagery and shp files as per the manual. When I open the image file - a Tif - the contents tab shows in black that it is WGS 84/pseudo mercator. As per Dimitri's instructions I should trust this is correct. I had downloaded it in NZTM - or so I thought. The shp file shows projection, in black as Transverse mercator, again I trust M9. I create a map using the projection the same as the image then b=drag the image file and then the shp file into the map. They are miles apart somewhere indicating a projection issue. i go back and repair the imagery projection to NZTM and everything works fine.

This might be a bug in our code interpreting the projection for either the TIFF or the SHP, yes. If the projection info is in the file and it is not getting read in full or at all, that's a bug.

Bugs like that are inevitable because defining projections is tricky. There is no common standard, just tons of disjoint bits and pieces with a lot duplication and a lot of gotchas specific to the formats and tools. (For TIFF files alone, the projection can be supplied in many different ways. And some of these ways look like "let's put this WKT string into a custom string tag, name that tag "my_projection_info" - the name is just an example - and hope that whoever reads the file understands that this should be interpreted as the projection'. It's a never-ending story. But we agree no one has to care about any of this, that's why we are calling all cases where the projection is not what is desired bugs and are constantly extending support for projections by checking rosters of other products, etc - this goes far beyond just reacting to bug reports.)

Please consider reporting the issue to tech support (instructions). This will allow us to fix it.

Manifold User Community Use Agreement Copyright (C) 2007-2017 Manifold Software Limited. All rights reserved.