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?

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.