[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] Projection WGS 84 as default
|
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
