-1 from me, because EPSG:0 is already reserved by the EPSG OGP Geodesy Subcommittee. Would you consider another integer >32767? Think of other extensions, like 900913. What is l33t for c4rt3514n (still missing a few digits)?
Furthermore, if we were to accept EPSG:0, would GeoServer start advertising it in its Capabilities? Kind regards, Ben. http://www.epsg.org/CurrentDB.html ****** EPSG Codes The OGP Geodesy Subcommittee has reserved the integer range 0 to 32767 for use as codes. As of dataset version 6.3, the integer range from 6,000,000 to 6,999,999 was also reserved for codes for geographic CRSs in explicitly described degree representations, but this is no longer supported. To prevent conflict with future additions to the EPSG dataset, users who wish to augment the data with their own information should utilise codes greater than 32768. If users wish to supplement the change table with their own entries, it is important that the user's change notice IDs be above the EPSG integer code limit of 32,767.0. Such an entry in the change table is required for users to deprecate any erroneous user data. ****** On 29/04/11 11:11, Michael Bedward wrote: > -0 from me. > > I understand the need and the rationale but I wish it wasn't necessary > to hijack the EPSG authority. > > Michael > > > On 29 April 2011 09:11, Ian Turton<[email protected]> wrote: >> On 28 April 2011 05:37, 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: >>> >> >> +1 for me (though I can already see newbies being confused by it :-) >>> ---------------- >>> >>> 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 >>> >> >> >> >> -- >> Ian Turton >> >> ------------------------------------------------------------------------------ >> 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 > -- Ben Caradoc-Davies <[email protected]> Software Engineering Team Leader CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ 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
