[Geoserver-devel] Generic cartesian CRS: code zero?

GeoServer GeoServer Developer
1

Hi,
I'd like to hear what people think about the idea of adding a new
custom EPSG code, EPSG:0, to GeoServer, to be used when no EPSG code can be
guessed from the data source (or when it's just plain missing).
EPSG:0 would map to DefaultEngineeringCRS.GENERIC_2D, which is designed to be
a lenient wildcard CRS, from the javadoc:

----------------

A two-dimensional wildcard coordinate system with x, y axis in metres.
At the difference of CARTESIAN_2D, this coordinate system is treated
specially by the
default coordinate operation factory with loose transformation rules:
if no transformation
path were found (for example through a derived CRS), then the
transformation from this
CRS to any CRS with a compatible number of dimensions is assumed to be the
identity transform. This CRS is usefull as a kind of wildcard when no
CRS were explicitly specified.

-----------------

The reasoning behind this idea is that way too often people do not
have, or do not know,
the CRS of their data, and are forced to guess with a valid EPSG code.
Maybe the data has no CRS to start with (think abusing GS/OL
to make an high resolution picture browser), maybe it's a building blueprint, or
a town level map made with CAD tools.
Or maybe it's GIS data but you just cannot find anything about the CRS
and you don't
care about reprojection to start with.

So far the common behavior by lots of people has been using EPSG:4326.
However that comes today with too many strings attached to be used as a default
for that case:
- it's geographic, thus it suffers from the axis flipping issue
- it can be wrapped, but the map wrapping heuristics will fail if the
data is not really
  within the limits of EPSG:4326 sane values

I guess the drawback for such a code is that it might confuse clients
that try to interpret
the codes (which are normally GIS aware ones).

Another possible for such data might be to pretend it's in a CRS that
is projected,
has a very large (possibly infinite?) ordinate validity range and
includes 0 as valid
value.. something like EPSG:3785 would indeed fit the bill.
The drawback of this one is that it would enable the usage of the reprojection
machinery while it makes no sense to use one.

Opinions?

Cheers
Andrea

--
Ing. Andrea Aime
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

2

I like the idea. The use case that strikes me as quite nice is someone having no idea what the epsg is, but just wanting to look at it in the layer preview. 0 seems like a nice way to represent that. And a nice way to get it in to our system where maybe they could figure out the epsg. With this there you could put in EPSG:0 and then use our force CRS to basically declare what the CRS should be after the fact, no? So you wouldn’t have to do your guessing before, you could just try various forces and seeing if they overlay right.

As for confusing clients - are thinking of advertising EPSG:0 in the capabilities document? I suppose we could consider not putting EPSG:0 layers in the caps documents, but exposing them in the layer previews and rest pages and let people make non-capabilities requests against them. Once someone declares a forceCRS it would then appear.

I like ESPG:0 more than 3785, as 0 is quite easy to remember.

On Sun, Jan 9, 2011 at 6:19 AM, Andrea Aime <andrea.aime@anonymised.com68…> wrote:

Hi,
I’d like to hear what people think about the idea of adding a new
custom EPSG code, EPSG:0, to GeoServer, to be used when no EPSG code can be
guessed from the data source (or when it’s just plain missing).
EPSG:0 would map to DefaultEngineeringCRS.GENERIC_2D, which is designed to be
a lenient wildcard CRS, from the javadoc:

A two-dimensional wildcard coordinate system with x, y axis in metres.
At the difference of CARTESIAN_2D, this coordinate system is treated
specially by the
default coordinate operation factory with loose transformation rules:
if no transformation
path were found (for example through a derived CRS), then the
transformation from this
CRS to any CRS with a compatible number of dimensions is assumed to be the
identity transform. This CRS is usefull as a kind of wildcard when no
CRS were explicitly specified.

The reasoning behind this idea is that way too often people do not
have, or do not know,
the CRS of their data, and are forced to guess with a valid EPSG code.
Maybe the data has no CRS to start with (think abusing GS/OL
to make an high resolution picture browser), maybe it’s a building blueprint, or
a town level map made with CAD tools.
Or maybe it’s GIS data but you just cannot find anything about the CRS
and you don’t
care about reprojection to start with.

So far the common behavior by lots of people has been using EPSG:4326.
However that comes today with too many strings attached to be used as a default
for that case:

  • it’s geographic, thus it suffers from the axis flipping issue
  • it can be wrapped, but the map wrapping heuristics will fail if the
    data is not really
    within the limits of EPSG:4326 sane values

I guess the drawback for such a code is that it might confuse clients
that try to interpret
the codes (which are normally GIS aware ones).

Another possible for such data might be to pretend it’s in a CRS that
is projected,
has a very large (possibly infinite?) ordinate validity range and
includes 0 as valid
value… something like EPSG:3785 would indeed fit the bill.
The drawback of this one is that it would enable the usage of the reprojection
machinery while it makes no sense to use one.

Opinions?

Cheers
Andrea

–
Ing. Andrea Aime
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers’ information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

On Sun, Jan 9, 2011 at 7:31 PM, Chris Holmes <chomie@anonymised.com> wrote:

I like the idea. The use case that strikes me as quite nice is someone
having no idea what the epsg is, but just wanting to look at it in the layer
preview. 0 seems like a nice way to represent that. And a nice way to get
it in to our system where maybe they could figure out the epsg. With this
there you could put in EPSG:0 and then use our force CRS to basically
declare what the CRS should be after the fact, no? So you wouldn't have to
do your guessing before, you could just try various forces and seeing if
they overlay right.

As for confusing clients - are thinking of advertising EPSG:0 in the
capabilities document? I suppose we could consider not putting EPSG:0
layers in the caps documents, but exposing them in the layer previews and
rest pages and let people make non-capabilities requests against them. Once
someone declares a forceCRS it would then appear.

I actually wanted to publish it in the capabilities. The reasoning is that it's
no different from any other custom code.
900913 is well known about open
source apps, but commercial apps do not know anything about it, yet we
commonly publish through it.
If you have a custom srs it's the same, you come up with a fancy code and
publish it.

So I think we should treat 0 just the same, it's our easy to remember custom
code, some client will have troubles dealing with it, yet if you're using it,
it means you don't have a meaningful epsg code to use anyways.

Cheers
Andrea

--
Ing. Andrea Aime
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

4

I like the idea. It sounds like a pretty good fit for this situation. I also like listing in capabilities and to the user since it makes it explicit that the crs is more or less uninitialized and was the servers final guess. +1.

How will/should this be introduced? Should we introduce a system property to engage it for the time being to give it a bit of testing before making it the default behaviour? Or perhaps a flag to turn it off in the event it leads to some unforseen issue?

On Sun, Jan 9, 2011 at 4:19 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
I’d like to hear what people think about the idea of adding a new
custom EPSG code, EPSG:0, to GeoServer, to be used when no EPSG code can be
guessed from the data source (or when it’s just plain missing).
EPSG:0 would map to DefaultEngineeringCRS.GENERIC_2D, which is designed to be
a lenient wildcard CRS, from the javadoc:

A two-dimensional wildcard coordinate system with x, y axis in metres.
At the difference of CARTESIAN_2D, this coordinate system is treated
specially by the
default coordinate operation factory with loose transformation rules:
if no transformation
path were found (for example through a derived CRS), then the
transformation from this
CRS to any CRS with a compatible number of dimensions is assumed to be the
identity transform. This CRS is usefull as a kind of wildcard when no
CRS were explicitly specified.

The reasoning behind this idea is that way too often people do not
have, or do not know,
the CRS of their data, and are forced to guess with a valid EPSG code.
Maybe the data has no CRS to start with (think abusing GS/OL
to make an high resolution picture browser), maybe it’s a building blueprint, or
a town level map made with CAD tools.
Or maybe it’s GIS data but you just cannot find anything about the CRS
and you don’t
care about reprojection to start with.

So far the common behavior by lots of people has been using EPSG:4326.
However that comes today with too many strings attached to be used as a default
for that case:

  • it’s geographic, thus it suffers from the axis flipping issue
  • it can be wrapped, but the map wrapping heuristics will fail if the
    data is not really
    within the limits of EPSG:4326 sane values

I guess the drawback for such a code is that it might confuse clients
that try to interpret
the codes (which are normally GIS aware ones).

Another possible for such data might be to pretend it’s in a CRS that
is projected,
has a very large (possibly infinite?) ordinate validity range and
includes 0 as valid
value… something like EPSG:3785 would indeed fit the bill.
The drawback of this one is that it would enable the usage of the reprojection
machinery while it makes no sense to use one.

Opinions?

Cheers
Andrea

–
Ing. Andrea Aime
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers’ information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

5

On Mon, Jan 10, 2011 at 6:47 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Sun, Jan 9, 2011 at 7:31 PM, Chris Holmes <chomie@anonymised.com> wrote:

I like the idea. The use case that strikes me as quite nice is someone
having no idea what the epsg is, but just wanting to look at it in the layer
preview. 0 seems like a nice way to represent that. And a nice way to get
it in to our system where maybe they could figure out the epsg. With this
there you could put in EPSG:0 and then use our force CRS to basically
declare what the CRS should be after the fact, no? So you wouldn’t have to
do your guessing before, you could just try various forces and seeing if
they overlay right.

As for confusing clients - are thinking of advertising EPSG:0 in the
capabilities document? I suppose we could consider not putting EPSG:0
layers in the caps documents, but exposing them in the layer previews and
rest pages and let people make non-capabilities requests against them. Once
someone declares a forceCRS it would then appear.

I actually wanted to publish it in the capabilities. The reasoning is that it’s
no different from any other custom code.
900913 is well known about open
source apps, but commercial apps do not know anything about it, yet we
commonly publish through it.
If you have a custom srs it’s the same, you come up with a fancy code and
publish it.

So I think we should treat 0 just the same, it’s our easy to remember custom
code, some client will have troubles dealing with it, yet if you’re using it,
it means you don’t have a meaningful epsg code to use anyways.

Ok, I didn’t feel strongly, so am convinced. Though would agree with Justin that we should have some caution, at the least an easy way to turn it off if things go awry.

Cheers
Andrea

–
Ing. Andrea Aime
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers’ information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

6

chiming in late due to vacations.

The idea is sound and needed. I'm wondering if there's any conceptual
difference between your EPSG:0 CRS and the CRS:1 special CRS defined in
the WMS 1.3 spec (see section 6.7.2 and 6.7.3.5). If there's not we
should use CRS:1, but I think there is a difference in that CRS:1
forcedly has a 0,0 coordinate origin and yours is tied to the layer
bounds as declared by the datastore?

In any case, CRS:1 seems worth to support at some point.

excerpt:
"6.7.3.5 Geographic information with undefined CRS
A server
may offer two-dimensional geographic information whose precise spatial
reference is undefined. For example, a hand-drawn historical map may
represent an area of the Earth but not employ a modern coordinate
reference system, and an aerial photograph may not be precisely
georeferenced. Such types of graphical information shall be treated as
an image, and the Map CS label “CRS:1” shall be used when declaring the
Layer CRS of such an object. Clients should not attempt to overlay a
layer for which CRS=CRS:1 with another layer."

Cheers,
Gabriel

On Mon, 2011-01-10 at 12:47 +0100, Andrea Aime wrote:

On Sun, Jan 9, 2011 at 7:31 PM, Chris Holmes <chomie@anonymised.com> wrote:
> I like the idea. The use case that strikes me as quite nice is someone
> having no idea what the epsg is, but just wanting to look at it in the layer
> preview. 0 seems like a nice way to represent that. And a nice way to get
> it in to our system where maybe they could figure out the epsg. With this
> there you could put in EPSG:0 and then use our force CRS to basically
> declare what the CRS should be after the fact, no? So you wouldn't have to
> do your guessing before, you could just try various forces and seeing if
> they overlay right.
>
> As for confusing clients - are thinking of advertising EPSG:0 in the
> capabilities document? I suppose we could consider not putting EPSG:0
> layers in the caps documents, but exposing them in the layer previews and
> rest pages and let people make non-capabilities requests against them. Once
> someone declares a forceCRS it would then appear.

I actually wanted to publish it in the capabilities. The reasoning is that it's
no different from any other custom code.
900913 is well known about open
source apps, but commercial apps do not know anything about it, yet we
commonly publish through it.
If you have a custom srs it's the same, you come up with a fancy code and
publish it.

So I think we should treat 0 just the same, it's our easy to remember custom
code, some client will have troubles dealing with it, yet if you're using it,
it means you don't have a meaningful epsg code to use anyways.

Cheers
Andrea

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

7

On Tue, Jan 11, 2011 at 1:30 AM, Gabriel Roldán <groldan@anonymised.com> wrote:

chiming in late due to vacations.

The idea is sound and needed. I'm wondering if there's any conceptual
difference between your EPSG:0 CRS and the CRS:1 special CRS defined in
the WMS 1.3 spec (see section 6.7.2 and 6.7.3.5). If there's not we
should use CRS:1, but I think there is a difference in that CRS:1
forcedly has a 0,0 coordinate origin and yours is tied to the layer
bounds as declared by the datastore?

In any case, CRS:1 seems worth to support at some point.

excerpt:
"6.7.3.5 Geographic information with undefined CRS
A server
may offer two-dimensional geographic information whose precise spatial
reference is undefined. For example, a hand-drawn historical map may
represent an area of the Earth but not employ a modern coordinate
reference system, and an aerial photograph may not be precisely
georeferenced. Such types of graphical information shall be treated as
an image, and the Map CS label “CRS:1” shall be used when declaring the
Layer CRS of such an object. Clients should not attempt to overlay a
layer for which CRS=CRS:1 with another layer."

Ah ha, nice to know about this one.
Might be a good fit, there are a few things to double check before
going down this road:
- in our code there is a widespread assumption that all codes are in the EPSG
  authority, consider for the example the axis flipping code in WFS
- EPSG:0 would also be usable as urn:ogc:, the same cannot be said about CRS:1
- what is the behavior of CRS:1 regards to reprojection? EPSG:0 would not
  throw exception in case of reprojection, would just never change the
coordinate
  values

In any case, the major concern about CRS:1 is its usability in WFS/WCS, I did
not check in detail but the gut feeling is that it might require
extensive changes to
be used there.

Cheers
Andrea

--
Ing. Andrea Aime
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------