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.
|