GoogleWebComponents
Support for GeoJSON
The Google Maps API has support for GeoJSON. I was wondering, if there’s any interest for having it in the <google-map> component (or if there is a particular reason that it wasn’t implemented).
Can't recall. Probably just a priority issue.
@brendankenny didn't we discuss at some point?
I think it was a matter of element architecture. I think there was an idea for GeoJSON child elements or something? I wasn't a fan of that one, personally, but I think this should absolutely be supported. If you have geographical data these days, odds are it's already in GeoJSON.
I think whatever the solution ends up being it should map as simply as possible to the Data Layer. Right now it's trivial to add GeoJSON to a <google-map> element: you can just go mapElement. map.data.loadGeoJson('https://somegeojsonurl.json');.
That could easily be exposed via an attribute or something, but you're left with questions about how to add more than one GeoJSON file to a single map (common occurrence) and removing the features from the map if the bound URL changed (probably less common).
Syling is a harder problem. Simple JSON-based styling is available, but note that the more useful general styling, while still declarative, is not valid JSON and has to be executed.
That's right. The discussion was around supporting this feature as a child element...which I also don't think is the right way to go.
I can see easily adding a src or geo-json-src attribute to pass a URL. Basic geo json first.
PR was submitted for this a while back: https://github.com/GoogleWebComponents/google-map/pull/87
I’ll gladly take a look a look/a part once I’m at peace with my current project
My take:
Every <google-map> has <google-map-data> object, exposed as property called 'data'.
<google-map-data> is a wrapper for google.maps.Data class. It exposes raw data, and provides convenience methods for loading geoJson, etc.
Hypothetical multiple geoJson example:
google-map-data
property: {
geoJsonUrls: {
type: object
observer: _geoJChanged
}
}
_geoJChanged: function {
syncs already loaded geoJsons and geoJsonUrls.
}
sounds like a behavior would be good for this. It could contain useful properties and methods for working with data.
You'd end up with <google-map> with a very large list of methods.
This architecture keeps us in sync with Maps API. They also separate data and the Map. They could have kept it together. For example, data has contains() method. Having that method on a Map would be confusing.
Good point. We should consider this an opt-in somehow. The vast majority of people won't use these advanced features. <google-map> is already fairly large as is.
