[udig-devel] Projection WGS 84 as default

[Jody Garnett]

Adrian Custer wrote:
> Jody, jody, jody...
>   
Good Morning!
> Do we both understand this totally? Is the message below completely
> redundant? I hope so, but in case there is *any* confusion left, here
> goes the pedantic rehash:
>   
Thanks for the recap; I do understand that what you are saying is right. 
But I have to keep thinking of ways to make
this easy. I am not sure if you understand that 90% of my difficulty 
with the proposed solutions comes down to popping
up a dialog, if I am going to pop up a dialog I want to do my very best 
to provide the user enough context to make an informed decision (perhaps 
looking at other files in the directory to see if they have a prj file, 
and then asking the user to confirm the "suggestion").

So I agree let's help them; and I am racking my brains to come up with 
an alternative to a dialog.
> On Fri, 2007-11-09 at 01:37 +0200, Jody Garnett wrote:
>   
>> Right; well here is what I am thinking. When I go into a GIS shop most 
>> times they just have directories full of shapefiles. No projections. The 
>> files are all in the same projection and everybody knows that and they 
>> don't bother to tell the tools (because that would be an extra step). 
>> uDig is one of the few tools that cares; how should we work with these 
>> shops that don't care?
>>     
> (1) let's help them; the theme to my earlier message 
>
> (2) they may be shops using 'GIS' but they sure aren't GIS shops---they
> aren't being serious. But this stuff requires being totally rigorous
> which may be hard the first time around, so (1) let's help them.
>
>   
>> I figure we have 30 mins of their time (usually 10 mins) and if this is 
>> slowing us down during that initial evaluation window then we need to do 
>> something about it. Another idea would be to prompt the first time a 
>> "unprojected" shp is loaded, 
>>     
>
> YES. uDig should deal with the missing CRS/prj info, once at the 'add to
> catalog' stage where we need to catch the missing CRS, and again at the
> 'add as map layer' stage where we need to warn about the missing
> projection. uDig should catch those and then be friendly by giving users
> a way to resolve the missing CRS or the missing projection. 
>
> This requires:
>
>         a) a split of the CRS and projection info/'open dialog' button
>         in the map editor. These should be separate buttons since I may
>         want to look at the different projections while keeping the CRS
>         the same. e.g. GPS data has a perfectly valid CRS but no
>         projection and a user may want to see it as 'unprojected',
>         'mercator' ...
>         
>         b) a dialog to catch users adding resources with no CRS to the
>         catalog. This would help users select or build a CRS. If users
>         don't know, then we build a cartesian CRS (but be aware we may
>         need to change this CRS by flipping axes once users see their
>         data). Also note this is almost certainly WRONG, i.e. not what
>         they really want, but it's the only 'default' we can possibly
>         have. So perhaps we don't write this CRS out but merely keep it
>         in memory as a virtual  'default'.
>         
>         c) a dialog to catch users adding a resource with no projection
>         information to an empty map. By default we fall back on a
>         cartesian projection (i.e. 'unprojected'). Actually, this could
>         be a simple warning with all the functionality built into the
>         'projection' button from (1).
>
> {You get that right? You can have coordinates in long/lat that have a
> perfectly valid CRS, but that CRS is without any projection info, e.g.
> GPS data. To display them, uDig needs to pick a projection:
> 'unprojected' i.e. straight to screen x/y; 'mercator'; UTM ... So even
> if the shapefile has a .prj file we are not out of the woods. (Actually,
> maybe that's wrong; maybe shapefile .prj always have the desired
> projection. Does the .prj of a GPS file actually always have a
> projection?)}
>   
I do understand, sorry if my last email came across as misunderstanding 
- I am more focused on the experience as easy as possible. We will have 
to check on the capabilities of a prj file.
> There is *no* default. There can be *no* default. If it were possible to
> have defaults we would have solved this issue in 1970. EPSG:42xx can be
> the current (incorrect) 'default' because it doesn't do anything---it
> has no projection, so it merely dumps the x/y coordinates to the screen,
> i.e. it is 'unprojected.' The only possible 'default' is:
>         a) CRS is cartesian
>         b) projection is 'unprojected'
>         c) no override 'lat before long' 
> so we dump the x/y coordinates of the resource directly to the screen
> x/y. We should be able to let users flip their x and y although I'm not
> sure how/where we could do that and where to store that setting. If
> users have digitized a map then this straight 'unprojected' dump is
> 'correct' in that it's keeping the projection of the original, whatever
> it may be.
>   
Let me rephrase; can we come up with any suggestions for them? The above 
cartesian/unprojected ie "raw data" is a suggestion of last resort. Here 
are some other suggestions:
- what they did last time? Chances are they want to do it again ... 
let's remember the previous values and maybe the user can just hit "OK"
- what they did last time on a per server or per directory basis .. even 
better. chances are that data that flocks together has the same problems
- "hardcore" look at the data range and rule out suggestions that don't 
"fit"
> The best way I can treat your words is: "How do we handle users that
> have lots of data with no CRS/projection information and don't want us
> to touch their files by adding any." Again, if they don't give us any
> extra information the only thing we can do is to dump their coordinates
> directly, unchanged to screen at most flipping the axes. So we 'default'
> to treating their data as cartesian, with no projection, with long
> before lat. (cont...)
>   
That is a good point. Especially for shops that re just trying uDig out; 
it is bad enough we
right little QNX index files on them, but that won't screw up other 
programs the same way writing a prj file would.

Thanks for talking this over with me; make it more important than ever 
that we get a more capable catalog that can hold onto extra udig 
specific information to fill in the gaps left by shoddy data practices.
> (cont) If users want to give us a 'setting', then this could,
> eventually, be kept and stored per 'service'. Indeed I'm going to want
> to do something like that with the NASA blue marble data since it's off
> in the highlands of Ethiopia so I want to be able to add a skewCRS to
> that service so all the data comming off that server gets slid over into
> the right place.
>   
That is an interesting story; I have always wanted a good real world 
example for the "override" story.
> But this solution is for tomorrow. It is going to require us to start
> tracking 'metainfo' about the resource, i.e. metadata that only we know
> about that resource. So we can't really start playing this game until
> (1) we clean up the catalog and (2) we start doing having a registry for
> our 'metainfo'. 
>   
Yeah got it; during FOSS4G I came up with the following plan:
- isolate the geotools catalog stuff to an unsupported/module
- update it with justin's geoserver configuration proposal (ie 
persistence based on xml or hibernate)
- I already have "wrappers" that can show a geotools catalog to the uDig 
catalog; this time I would directly subclass and give the geotools 
catalog a factory so it creates entries that implement to uDig IResolve 
interface. Thinking: now that GeoTools is Java 5 perhaps we could just 
leave that step out....
> With that, I'm going back to the storage API's.
>   
Cool; thanks for the great conversation Adrian. I would like to gather 
your summary onto the wiki.
Jody