Stream: implementers
Topic: Input on representing geoshape data in FHIR
Cooper Thompson (Jan 31 2018 at 15:43):
In gforge ticket 13391, PA is in agreement that we want to be able to be able to include the boundary shape for a location, however we are not exactly sure how we should represent it. There are competing standards for geo shapes (geoJSON, KML, GML, ArcGIS (which is proprietary, but common). One option is to make the boundary shape a backbone element with a content-type + base64binary, so that folks can use any shape format they want. However that makes exchanging shapes harder as all parties need to either pre-coordinate what format is used or support everything.
Do folks have any input or opinions on how we should include geo-shape representations?
Josh Mandel (Jan 31 2018 at 15:46):
My main input: let's not provide a generic binary blob! It'd be better to define extensions for individual formats boundsAsGeoJSON, boudnsAsKML, etc).
Josh Mandel (Jan 31 2018 at 15:47):
Better than than, I'd like to see if we can "pick one" preferred way. @Cooper Thompson if you got to pick, do you know what it'd be?
Michael Donnelly (Jan 31 2018 at 15:49):
PA considered having options because we don't know which format will win out.
Cooper Thompson (Jan 31 2018 at 15:55):
As one hasn't "won out" in the past several decades, it is unlikely there will be one winner. There will likely always be several alternatives available. The area I'm most worried about is if a new popular format arises. If we pick a format now, we would be slow to respond to new formats.
Josh Mandel (Jan 31 2018 at 15:58):
I wouldn't worry so much about future winners as I'd worry about functionality: what do we need, and is there a popular, well-supported, open standard today? If there's something good enough, we should satisfice.
Josh Mandel (Jan 31 2018 at 16:02):
Looking at KML vs GeoJSON, the latter spec is ~1/10 the size; if it meets our requirements, that seems like a defensible choice.
Michael Donnelly (Jan 31 2018 at 16:06):
@Cooper Thompson Do you think it would be better to make it a standard extension?
Cooper Thompson (Jan 31 2018 at 16:21):
If we pick one, standard extension seems better, as it give us more flexibility around changes once things go normative. But I don't personally have a strong opinion about base spec vs. extension.
Michael Donnelly (Jan 31 2018 at 16:22):
@Brian Postlethwaite ?
Brian Postlethwaite (Jan 31 2018 at 17:00):
If we can agree on a format, I'm happy for core, but certainly happy with a standard extension
Brian Postlethwaite (Jan 31 2018 at 17:00):
I'll do some digging and create some examples
John Moehrke (Jan 31 2018 at 18:12):
can we provide a blob, and a mime-type element for that blob? This is how we solve in the Digital Security space, where there are many standards without a clear winner.
Elliot Silver (Feb 01 2018 at 15:19):
@Luke Duncan , you have an interest in this. Do you have some thoughts?
Luke Duncan (Feb 01 2018 at 18:51):
I'm no expert on the GIS side of things, but for my particular use case, all I need is a way to represent a polygon. Do we want ways to represent other geometries? For my case a list of lat/long coordinates would suffice, but perhaps that's too simple and maybe not enough information to turn that into something more complicated like KML. There are tools that can be used to convert various formats so @John Moehrke 's suggestion would work for me. I would also be happy for it to be in core for something similar to location.position, but a standard extension would also work.
Abbie Watson (Feb 04 2018 at 15:19):
As one hasn't "won out" in the past several decades, it is unlikely there will be one winner. There will likely always be several alternatives available. The area I'm most worried about is if a new popular format arises.
The new popular format _is_ GeoJson. :)
As an aside, I've implemented FHIR based geomapping with Google Maps and GeoJson with great success. +1 for GeoJson. KML will be needed for legacy pre-web GIS support. But since FHIR is based on webstandards, focus should be on providing first class support for GeoJson.
As I've posted elsewhere, we may want to consider pulling in the GeoJson Spatial primitives, and positioning them next to Datatypes.... Point, Multipoint, Line, Circle, etc. And then defining a Map resource (which is essentially what a geojson file already is).
I have pilot ready apps if anybody is interested. They support geoshapes for boundaries of counties, health service areas, neighborhoods, paratransit/ambulance routes, etc. etc. All the good stuff (licensable though; not free; gotta pay the rent).
Grahame Grieve (Feb 04 2018 at 20:31):
why would we define a Map resource if geoJson exists?
Lloyd McKenzie (Feb 04 2018 at 21:36):
Can we convert the geoJason to XML and RDF?
Brian Postlethwaite (Feb 04 2018 at 22:42):
I wouldn;t suggest that we did try to make the map datatype a fhir datatype, and just use the appropriate 3rd party standard with the widest most appropriate support.
Others will need to be mapping to/from that anyway.
Lloyd McKenzie (Feb 04 2018 at 22:44):
It does mean that the XML people will need to be able to parse JSON - is that going to create any challenges?
Grahame Grieve (Feb 04 2018 at 23:30):
I personally don't think that the lack of XML support in GeoJson is enough to justify us buying into duplicating the format
Last updated: Apr 12 2022 at 19:14 UTC
