The idea sounds good and well thought out to me. I think it is fine to
ignore CRS:1 for now. A simple fix for geoserver woud to be do a replacement
on request handling (like the way we solve the axis ordering issue). But
that is out of scope here.

+1 on both trunk and 2.7.x.

-Justin

On Thu, Apr 28, 2011 at 4:09 AM, Jody Garnett <[email protected]>wrote:

> Thanks for the summary Andrea; I suspect your could define both "EPSG:0"
> and CRS:1" as backed on to the same class. We do allow coordinate reference
> systems to list multiple identifiers so this would not be out of place.
>
> You may also wish to steal some of the documentation from CRS:1 in
> describing this beast.
>
> With respect to the concept, I think it is a clear idea, and will be
> well received.
>
> Jody
>
> On Thu, Apr 28, 2011 at 7:37 PM, Andrea Aime <[email protected]
> > wrote:
>
>> Hi,
>> some months ago I started a discussion on GeoServer devel about
>> adding support for a new EPSG code, EPSG:0.
>> (if you want to review that discussion see here:
>>
>> http://osgeo-org.1803224.n2.nabble.com/Generic-cartesian-CRS-code-zero-td6136122.html
>> )
>>
>> ESPG:0 would represent pure cartesian data, lack of any referencing, and
>> would
>> thus be associated 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 only different would be that this one would be constructed so that it
>> reports being EPSG:0 as being its "name".
>>
>> The idea behind EPSG:0 is to be able to handle non georeferenced data,
>> or data that is expressed in some unkonwn coordinate system.
>> This would allow to natively handle CAD data in vector land and plain
>> images in raster land still using our GeoTools Feature/Coverage concepts,
>> and avoid users to try and force EPSG:4326 in it instead (because it's
>> often
>> the only code they remember).
>>
>> As far as I can see this fits well with our existing code base, that
>> already
>> uses in some places  DefaultEngineeringCRS.GENERIC_2D when no
>> native CRS could be found, this work would just give it a name.
>>
>> Gabriel on the old thread raised a good point that the WMS 1.3 spec also
>> has
>> CRS:1 as the identifier to be used for the same purpose.
>> I'm not going to go down that road because this would require making a
>> large
>> amount of changes to many bits of existing code assuming the authority
>> is always going to be ESPG, both in GeoTools and GeoServer.
>> The day we go there and allow the library to function properly without
>> those
>> assumption its going to be easy to add a further alias to that CRS
>> and have it respond as CRS:1 as well.
>>
>> To wrap up, I'd like to add a new authority factory in referencing that
>> adds support for that code and then check that base stores and coverage
>> readers are working properly with it.
>> Since this is an addition it's not going to break code not using it,
>> thus I propose to commit the changes on both trunk and 2.7.x
>>
>> Opinions?
>>
>> Cheers
>> Andrea
>>
>> --
>> -------------------------------------------------------
>> Ing. Andrea Aime
>> GeoSolutions S.A.S.
>> Tech lead
>>
>> Via Poggio alle Viti 1187
>> 55054  Massarosa (LU)
>> Italy
>>
>> phone: +39 0584 962313
>> fax:      +39 0584 962313
>>
>> http://www.geo-solutions.it
>> http://geo-solutions.blogspot.com/
>> http://www.youtube.com/user/GeoSolutionsIT
>> http://www.linkedin.com/in/andreaaime
>> http://twitter.com/geowolf
>>
>> -------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------------
>> WhatsUp Gold - Download Free Network Management Software
>> The most intuitive, comprehensive, and cost-effective network
>> management toolset available today.  Delivers lowest initial
>> acquisition cost and overall TCO of any competing solution.
>> http://p.sf.net/sfu/whatsupgold-sd
>> _______________________________________________
>> Geotools-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to