Hi, We are helping customers use EDG in the domain of asset management, where GIS is always important. Our strategy so far has been: use a (top of the bill) GIS system (like ArcGIS Pro) for GIS, and cross-link between that and EDG. In that way, users are just a mouse click away from the asset detail view (from the GIS-system) or the geo-view (from EDG).
Of course, when cross-queries are desired, some sort of data duplication is needed, either from EDG to the GIS-system, or the other way around. When data is duplicated from the GIS-system to EDG, use case for GeoSPARQL become relevant. There is a lot of interest in this, but concrete use cases are difficult to come by. A heavy user of GeoSPARQL is Kadaster (they do not use EDG). I could ask for some concrete descriptions of what they do. In general, it is queries like "select all buildings of type Church with construction year < 1900 in the area of municipality X". Such queries become more and more important with the digitalization of environmental laws and regulations. I would (of course) applaud any movement in the direction of GeoSPARQL: the more the better. That said, it is important to be aware of the limitations. Selecting ranges on, say, a bent clothoid (as in a ramp on a freeway intersection) is something that needs highly specialized software, not a generic GeoSPARQL-implementation. Best, -j -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Holger Knublauch Sent: 17 February 2020 06:12 To: [email protected] Subject: [topbraid-users] GeoSPARQL Support ? Dear Users, we had a number of requests for support of GeoSPARQL (or similar) in TopBraid EDG. If your group has use cases for this, could you kindly let us know - either by responding to this mailing list or by mailing me directly? I suspect that a common use case would be "find all resources that have geo:lat/long within a given bounding box". This would align well with the typical Google Maps query where the map displays all items within the currently visible rectangle. It would also provide a good approximation of "find me everything within a certain radius". Are there any other urgent use cases, and how would you rate them compared to the bounding box scenario? Background of this question is whether we really need to expose the full GeoSPARQL feature set or whether we could design an interface with a much smaller footprint and with less implementation and maintenance burden. A smaller footprint would allow us to swap the implementation without breaking existing installations, and of course may get us to a deliverable faster. Thanks Holger -- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/c510a419-6e6d-787c-87e7-c8316a85a716%40topquadrant.com. -- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/AM4PR0301MB2131D3F926C294BC450C685AE9160%40AM4PR0301MB2131.eurprd03.prod.outlook.com.
