Is there currently a best practice for adding a geographical location to an object in a data model?
I’ve considered simply using a string property to my model containing wkt-formatted strings, or a GeoSpatial feature external id, but none of them seem ideal. I assume there is a size limit on strings - so that wkt might be a bad choice?
We’ve previously discussed this for timeseries, where you mentioned that data model geolocation was on the roadmap. Any update on this? 
I believe you are on the right path here, i.e. WKT is the canonical way to express this. Have you tried it and run into size limitations?
I haven’t tried, but thought I previously heard something about size limitation for string properties - I might be wrong, though.
I heard some rumors about a plan to support geoobjects as a native type in data models. So we decided to postpone the inclusion of geo-information in our enterprise model until we hear more about the future roadmap for this feature.
I don’t know what the actual limit is so instead I’ll paraphrase Nike: “Just try it!”
I.e. make a big WKT, including all the datum/ellipsoid/vertical datum information along with UTM and/or lat/lon coordinates and test if you can both write it and read it back correctly.
OK?
+2
Hi
We are following up to see whether you're satisfied with the responses you've received?
Hi
We are following up to see whether you're satisfied with the responses you've received?
Thanks for following up. Yes, albeit I was hoping for a more standardized way to handle geoLocation in datamodels. Say, a specific geolocation type where one might put restrictions to guarantee only using valid wkt-strings, possibly filtering a search on types of polygons etc. We’ve decided not to pursue this path any further for now, but might return to it at a later stage.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
