JTS' orginal design intent was to implement the OGC Simple Feature
Specification. For that reason it provided the getSRID method, which the
spec defines as having an integer value. However, JTS provides no
coordinate system handling or operations itself, so really the SRID has no
semantics within JTS.
As you point out, this has somewhat limited practical utility. It might
have been better to define the SRID as an object, or even simply a string.
Either would have given more flexibility.
Your idea of storing required CRS information external to the geometry is a
fine one, and is what many JTS clients do.
On Mon, May 5, 2014 at 12:46 PM, Eugene Cheipesh <[email protected]>wrote:
> Hello,
>
> I am part of GeoTrellis project where we are creating a Scala wrapper
> around JTS. One issue that we have is the treatment of SRID field.
>
> I am hoping to hear from either the developers that made the original
> design choice to include SRID field or people using the feature. I would
> really love to know what is the design intent behind storing SRID with each
> geometry and if it has born out over time.
>
>
> It seems like SRID is somewhat semantically overloaded. They seem to exist
> in either of two states:
>
> 1. There is no meaningful value for SRID, or perhaps all the geometries
> have the same values. Regardless, all the operations are valid and one
> writes code as if SRID field doesn't exist.
>
> 2. Geometries must be written somewhere where several SRIDs are possible,
> for instance different PostGIS columns. Alternatively geometries are read
> from some source with multiple SRID values and the one may want to match
> SRIDs to ensure the result of operations on geometries are meaningful.
>
> However in this case the value of SRIDs has to be an index into some
> undefined table, possibly EPSG, possible something else. In this way they
> seem to carry only some information needed to fully qualify the geometry
> coordinates.
>
>
> An alternative design choice might be to construct a tuple with a Geometry
> and a CRS object whenever serializing or deserializing geometries. The CRS
> would contain all the information to qualify SRID, proj4 code, as well as a
> name. This is much heavier than a single integer field but on other hand
> more explicit in those cases where SRIDs matter.
>
> Thank you,
>
> --
> Eugene Cheipesh
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find
> out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Jts-topo-suite-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>
>
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Jts-topo-suite-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
