I understand the concerns completely, and have no opinion either way... The only thing I'm pushing for is the SRID property on the geometry object. In an object oriented system, it's normal to keep encapsulated data together. In the case of geometries, there is an SRID associated with that data. In a homogenous system, you just make assumptions all the way through (or convert everything on entry or exit from the system). If you need to have geometries with different SRIDs, however, you need to keep track of the SRID per object, and in an OO system, it makes sense to store that as a property of the geometry.
What's more, there's a standard which GEOS tries to implement to some level of compliance, (as does Shapely) I don't see the argument for cutting out that one point. Shapely doesn't care about the data, neither does GEOS, it's just a convenience for developers who need to work in a heterogenous system. As to whether to use integers or some other system, I would try to keep in line with the standard. OGC has decided on EPSG SRIDs, which are integers, and so that is appropriate. Since it's Python, however, if you wanted to lift the restriction, that doesn't bother me either. Thanks, Douglas Mayle On Jun 12, 2009, at 8:22 AM, Nino Walker wrote: > I had a similar concern about the lack of a SRID and reprojection > capabilities when I first started working with shapely, but have since > come to the conclusion that it would be a distraction from the core > functionality and simplicity of the API. It's absence simply raises > the bar and makes sure you think about and understand fully the data > you're working with. > > And, pyproj is relatively painless to work with as a separate step. > So, I echo Sean, and I am in favor of putting the onus on the app/ > script/developer to manage the accounting/reprojecting aspects of the > inputs and outputs. > > Nino > > On Jun 11, 2009, at 2:32 PM, Sean Gillies wrote: > >> I've wrestled with this issue quite a bit, though not recently. An >> SRID method is definitely part of the OGC Simple Features Access >> interface (OGC 06-103r3) that Shapely approximately implements. It's >> supposed to return an integer, which not only supposes that you >> have a >> model that includes coordinate systems, but that you identify >> coordinate systems with integers. Would you want to use ints with >> Shapely? Object references? Weakrefs? >> >> I've considered Shapely's model agnosticism to be a feature rather >> than a bug, and haven't considered transparent crs handling under >> geometry operations to be a killer feature. I prefer to make the >> transformations explicit, but am open to other opinions. >> >> Sean >> >> On Jun 11, 2009, at 1:27 PM, Douglas Mayle wrote: >> >>> I understand that GEOS and Shapely don't care about coordinate >>> systems, and that's not an oversight. I meant the fact that the >>> GEOS >>> slot for SRID (which is part of the standard for geometries) is not >>> exposed in Shapely. At some point, someone may care about the SRID >>> of >>> the data and want to do something with it... >>> >>> Doug >>> >>> On Jun 11, 2009, at 9:23 PM, Sean Gillies wrote: >>> >>>> Not an oversight. Like you said, GEOS doesn't understand coordinate >>>> systems. It is only concerned with planar geometry. Shapely, >>>> likewise. >>>> Coordinate systems are (IMO) a concern of features and layers (or >>>> feature collections). >>>> >>>> Sean >>>> >>>> >>>> On Jun 11, 2009, at 12:59 PM, Douglas Mayle wrote: >>>> >>>>> Hello everybody... >>>>> After talking with Paul Ramsey, I understand the GEOS, the c >>>>> library >>>>> behind Shapely has an SRID slot for the geometry object. It >>>>> doesn't >>>>> know enough to do anything with it, but at least you can track the >>>>> SRID of the object you're working with. This doesn't seem to be >>>>> exposed in Shapely. Of course there's no problem in simply adding >>>>> an >>>>> attribute (yay python!), but I was wondering if this was a simple >>>>> oversight? >>>>> >>>>> Thanks, >>>>> Douglas Mayle >>>>> _______________________________________________ >>>>> Community mailing list >>>>> [email protected] >>>>> http://lists.gispython.org/mailman/listinfo/community >>>> >>>> _______________________________________________ >>>> Community mailing list >>>> [email protected] >>>> http://lists.gispython.org/mailman/listinfo/community >>> >>> _______________________________________________ >>> Community mailing list >>> [email protected] >>> http://lists.gispython.org/mailman/listinfo/community >> >> _______________________________________________ >> Community mailing list >> [email protected] >> http://lists.gispython.org/mailman/listinfo/community >> > > > _______________________________________________ > Community mailing list > [email protected] > http://lists.gispython.org/mailman/listinfo/community _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
