Skip to main content

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?


Hi @Kristian Nymoen,

We are following up to see whether you're satisfied with the responses you've received?

 


Hi @Kristian Nymoen,

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.


Reply