Stream: implementers
Topic: Location & geojson
Abbie Watson (Jun 16 2017 at 14:37):
So, this past week I ran into a wtf? moment while trying to to use the Location resource to geocode the hospitals associate with Medicare Health Service Areas (HSA) and display them on a Google Map. So, like.... why isn't Location structured as a geojson resource??? This is such an obvious data structure, with widespread support and implementation via the GIS community and geodatabases. Did HL7 simply not want the overhead of supporting Point datatypes? Are people actually using the XML version of Location in a substantial capacity so they didn't think about geojson? I don't understand how this resource got to be the way it currently is.
Elliot Silver (Jun 16 2017 at 16:41):
I don't know anything about geojson, but please look at GF#10234 and GF#13391, and add your comments there if appropriate. There have been other calls for richer geospatial information in Location.
Abbie Watson (Jun 16 2017 at 17:43):
Ah! Thank you. These links are exactly what I was hoping to find. I'll draft some thoughts and post them to gForge.
Abbie Watson (Jun 16 2017 at 17:58):
Some musings... the more I look into this though, for Location to align with GIS systems is going to require a fairly big ask of FHIR whether it wants to support Point, Line, Polygon, and other geospatial primitives. Location is very similar to what GIS considers a Feature. What's really interesting about geojson though is that it basically defines a Map resource (basically a List of Features), and supports a feature field which is perfect for storing FHIR resources. That part of my project worked great, and we can lay FHIR resources directly into our geojson and do really great maps with them. But Location.positionis fairly nonstandard, and can't be used for a geospatial 2sphere index or $near operators or anything. We can do some boxing/unboxing and use a different storage format than the wire protocol. Not the end of the world. But it would be a heck of a lot cleaner if we had a Point primitive.
How much of an ask would it be to define a Map resource and a set of geospatial primitives like Point, Line, Polygon, etc? Is that like, asking to move mountains? Or would it just be a routine ask as part of the maturation process and aligning/harmonizing with GIS systems?
Grahame Grieve (Jun 16 2017 at 21:48):
I had not heard of geojson before now. We looked at kml and a few others originally.
Grahame Grieve (Jun 16 2017 at 21:49):
Why would we define a map resource if geojson does it?
Brian Postlethwaite (Jul 04 2017 at 05:34):
The location could be a point, or a region. Currently only covers the point option, and the trackers have been suggesting ways to define the region part.
Brian Postlethwaite (Jul 04 2017 at 05:34):
Thanks for the additional feedback @Abigail Watson. Note that there's also the extension on address for storing the patient's address which I've been using to plot patients for community routing
Abbie Watson (Jul 05 2017 at 19:16):
I think defining a Map resource would be perfunctory, and a way for FHIR to simply bless the format that's been developed by the GIS folks for web interoperability. They've done a lot of work already with the geojson format, and it's right there for FHIR to use and adopt.
There's a little bit of harmonizing left to do though.... the GIS folks use a 'Type' field instead of 'resourceType', for instance. And defining a FHIR Map resource might put some grist in the mill so we can talk to them about supporting synonyms.
Regarding kml and geojson.... they're both pretty standard, with geojson being more lightweight.
However, they both have the problem of topology slivers (i.e. multiple polygons being lined up close to each other, but not contiguously, which introduces slivers). There's also a .topojson format that supports reduced line contiguous shapes, and uses the same Feature resource that .geojson does. And if we take a look at database popularity, it's pretty clear that there are many more JSON database than XML database... and fewer KML databases. It just seems there's fairly good support for geojson from Mongo, CouchDB, Postgresql, etc. But KML support gets pretty esoteric.
Last updated: Apr 12 2022 at 19:14 UTC
