GNOME Bugzilla – Bug 749067
Implement GeoJSON support
Last modified: 2015-10-27 07:35:23 UTC
Opening and displaying geographic annotation and visualization, possibly through KML/KMZ files is already in the roadmap, but there was no bugreport to track this: https://wiki.gnome.org/Apps/Maps/Roadmap https://en.wikipedia.org/wiki/Keyhole_Markup_Language A developer documentation can be found here: https://developers.google.com/kml/documentation/?csw=1 Google even provides a library to work with KML: https://github.com/google/libkml And just as additinal information: KDE Marble and Google Earth are able to im- and export KML/KMZ files. DigiKam and darktable have KML/KMZ exports for images with GPS informations. KMZ is just a ZIP compressed KML file.
Thanks for doing this Tobias! Hopefully someone will want to work on it as well!
This might make a nice gsoc / outreachy project, at least investigating it.
*** Bug 753656 has been marked as a duplicate of this bug. ***
It might be easier to start with GeoJSON, since we are an javascript application, the parsing would be trivial.
http://geojson.org/geojson-spec.html
There's some resources and code here[1] as well for converting KML, WKT, GeoCSV, GPX etc. Might be worth taking a look at. 1: https://github.com/mapbox/leaflet-omnivore
Created attachment 310793 [details] Image of applied shape file Some though for how this should work UI/UX wise would be nice. Andreas, Allan? Any thoughts? It is about the ability to add shapefiles/layers, sort of like the shapes in the attached image.
I have no prior knowledge of this, so sorry for asking stupid questions. So this is for displaying custom things that are not in OSM as a layer on top of our current layers? How does the different use cases work?
Don't be sorry this is not at all common knowledge and the bug was lacking in details! So to my knowledge, others can probably explain better: So, this is about opening shapefiles with Maps. A shapefile can hold shapes. Like polygons, points, lines and so on. Along with some meta-data about those shapes. Like color, name and other stuff. These files can be in different formats, that are standard formats and use more or less in different industries or by hobbyists. So say someone creates a shapefile for all the municipalities in sweden, and draws their borders. We could open that. Or someone plots all the McDonalds in the USA, we could open that and show it. So I guess the use case is someone does a neat layer and we download it, and our browser asks us if we want to open it in Maps. And we view the cool layer. Maybe we do a GUADEC shapefile that show places in the GUADEC town that are important.
Ah, thanks for the info. What kind of information is common for the formats to have? Does the file usually itself have a title, more than the filename? ie. "GUADEC 2016 map" vs. guadec2016.kml
Maybe this can answer some things. I think it is GeoJSON and KML that are what we want for Maps: http://apprentice.craic.com/tutorials/28 I do not think we can rely on a title, but it could be there. Sort of like how PDFs are I think.
Hi I'm really interested in contributing in this project with/without OPW, can anyone please tell me what are technical knowledge we need to have and how to proceed working in this direction. Thank You!!
Hi! I am working a bit on doing this for geojson, I am hoping to soon publish a branch with the code I have so far. I think reading the links already on this page would be a nice start. Also getting a jhbuild environment up to build Maps from source would be nice. There is a very good newcomers tutorial for GNOME to help you get started: https://wiki.gnome.org/Newcomers/ And the Maps page contain more information on how to contribute to Maps: https://wiki.gnome.org/Apps/Maps After you've gotten a developer environment up and running for Maps, you and I can discuss which way to go with this? Maybe reading up some on KML would be nice! Thanks Jonas
Created attachment 313957 [details] [review] Add geojson-vt from Mapbox Geojson-vt is A highly efficient JavaScript library for slicing GeoJSON data into vector tiles on the fly, primarily designed to enable rendering and interacting with large geospatial datasets on the browser side (without a server). https://github.com/mapbox/geojson-vt, see LICENSE for license.
Created attachment 313958 [details] [review] Add and convert geojson-vt to GJS
Created attachment 313959 [details] [review] Add GeoJSONSource Add a Champlain::TileSource that creates tiles from a GeoJSON file. This is based on the geojson-vt library from Mapbox.
Created attachment 313960 [details] [review] mapView: Add openGeoJSON method
Created attachment 313961 [details] [review] application: Handle open GeoJSON files
Created attachment 313962 [details] [review] mainWindow: Add drag and drop support for GeoJSON
Created attachment 313963 [details] [review] Add GeoJSON mimetype
Some casts of the functionality: https://www.youtube.com/watch?v=zpiUaSxY4Ho&feature=youtu.be https://www.youtube.com/watch?v=j9wEVHqWEI0&feature=youtu.be https://www.youtube.com/watch?v=nKkW1sWq2o8&feature=youtu.be
Created attachment 313964 [details] Geojson of municipalities in Norway A test file, you could try this with the page geojson.io to see how the rendering differs. (they fill in the polygons with 0.5 opacity gray)
Review of attachment 313958 [details] [review]: ::: src/Makefile.am @@ +7,3 @@ $(shell $(GLIB_COMPILE_RESOURCES) \ --sourcedir=$(srcdir) \ + --sourcedir=$(srcdir)/geojson-vt \ Maybe it's better to not add this line and write the "geojson-vt/" prefix in the gresource.xml. How GResource handles filename clashes in cases like this?
Review of attachment 313958 [details] [review]: ::: src/Makefile.am @@ +7,3 @@ $(shell $(GLIB_COMPILE_RESOURCES) \ --sourcedir=$(srcdir) \ + --sourcedir=$(srcdir)/geojson-vt \ Yeah I agree with Damián here. @@ +15,3 @@ $(AM_V_GEN) $(GLIB_COMPILE_RESOURCES) \ --target=$@ \ + --sourcedir=$(srcdir)/geojson-vt \ Same here in that case?
Review of attachment 313959 [details] [review]: Cool stuff! Some comments below. ::: src/geoJSONSource.js @@ +25,3 @@ +const Mainloop = imports.mainloop; + +const geojsonvt = imports.index.geojsonvt; Hm. This import line doesn't look good. :/ Would it be possible to make the geojson-vt import get you something like this instead: > const Geojsonvt = imports.geojsonvt; and then use that as Geojsonvt.geojsonvt() below? That is: rename index.js to geojsonvt.js and just import the module in the import line not also the function. If that feels awkward when we want to sync with geojson-vt in the future, then perhaps fix it in the resource-file (that works right?) or add a new module re-exporting index.js In the node.js world index.js is pointed out by some field in package.json so you'd actually do require("geojsonvt") in most projects (which is what we also want to do to stay consistent :)) @@ +53,3 @@ + + vfunc_get_tile_size: function() { + return 256; This value is used a lot later on. Perhaps make a constant out of this? @@ +65,3 @@ + + vfunc_get_id: function() { + return 'geoJSONSource'; GeoJSONSource instead? @@ +69,3 @@ + + vfunc_get_name: function() { + return 'geoJSONSource'; GeoJSONSource instead? @@ +81,3 @@ + tile.display_content(); + } + else if(this.next_source) Remove newline before else. :P @@ +85,3 @@ + }).bind(this)); + + Remove extra empty line. @@ +96,3 @@ + return false; + + return true; > return (-180 <= coordinate[0] && coordinate[0] <= 180) > && ( -90 <= coordinate[1] && coordinate[1] <= 90); That way it looks like the classic mathematical "between"-expression. That is: (-180 ≤ c₀ ≤ 180) ∧ (-90 ≤ c₁ ≤ 90) @@ +160,3 @@ + + return false; + }, Hm. I'm a bit unsure about a function named validate* that not only validates but also adds stuff to the map. Perhaps split this up some how? @@ +172,3 @@ + } else if (root.type === "Feature") + return this._validateFeature(root); + root.type can also be Point, MultiPoint, Polygon, MultiPolygon, LineString, MultiLineString and GeometryCollection. This is how Leaflet does this: https://github.com/Leaflet/Leaflet/blob/master/src/layer/GeoJSON.js#L76 (which might be of interest).
Review of attachment 313959 [details] [review]: One question I have is what do we do if the provided GeoJSON contains a bbox property? Do we just ignore it and assume it is bogus and calculate our own or should we try to rely on it? ::: src/geoJSONSource.js @@ +111,3 @@ + + _validateLineString: function(coordinates) { + return this._compose(coordinates); Hm, this doesn't /just/ validate it also extends the bounding box. Maybe split up? @@ +117,3 @@ + for (let i = 0; i < coordinates.length; i++) + if (!this._compose(coordinates[i])) + return false; Same here.
Review of attachment 313960 [details] [review]: The code looks good. Not sure about where we want to go design wise with this. Do we want to save the overlay data (in this case geojson) for further use? Should the user be able to toggle many overlays at once?
Review of attachment 313961 [details] [review]: LGTM
Review of attachment 313960 [details] [review]: Hm let's make this commit_now. Meaning that the code looks good.
Review of attachment 313962 [details] [review]: Small nit. Else looks good! ::: src/mainWindow.js @@ +95,3 @@ + Gtk.drag_finish(ctx, false, false, time); + } + }).bind(this)); I don't like how the constructor is constantly growing in mainWindow.js Perhaps move this out to an initDnd-function?
Review of attachment 313963 [details] [review]: ::: data/maps.xml @@ +6,3 @@ + <glob pattern="*.geo.json"/> + </mime-type> +</mime-info> Will this file only contain mime-data? The name maps.xml doesn't seem very descriptive if that's the case. Perhaps geojson.mime.xml or something?
Great work Jonas!!
And, btw. I should note that this review is just on pure style. I wasn't able to quickly compile Maps because of the new geoclue stuff (but will try again later).
Review of attachment 313958 [details] [review]: Thanks guys! ::: src/Makefile.am @@ +15,3 @@ $(AM_V_GEN) $(GLIB_COMPILE_RESOURCES) \ --target=$@ \ + --sourcedir=$(srcdir)/geojson-vt \ I will still add these, but add an alias in the gresource so that they are treated as geojson/module.js, this will break running maps from the local repo. But maybe noone does that? Eg. ./src/org.gnome.Maps
Review of attachment 313959 [details] [review]: stupid question: Isn't this generic enough to go into Champlain itself?
Review of attachment 313959 [details] [review]: ::: src/geoJSONSource.js @@ +25,3 @@ +const Mainloop = imports.mainloop; + +const geojsonvt = imports.index.geojsonvt; Along with the comment earlier, this would be: const Geojsonvt = imports.geojsonvt.geojsonvt; And then Geojsonvt.geojsonvt below. @@ +53,3 @@ + + vfunc_get_tile_size: function() { + return 256; Sure! @@ +65,3 @@ + + vfunc_get_id: function() { + return 'geoJSONSource'; Yes! @@ +160,3 @@ + + return false; + }, Will call it parse instead. @@ +172,3 @@ + } else if (root.type === "Feature") + return this._validateFeature(root); + Thanks, improved it somewhat. I do not want to support MultiPoint yet tho, will think on it.
Review of attachment 313963 [details] [review]: ::: data/maps.xml @@ +6,3 @@ + <glob pattern="*.geo.json"/> + </mime-type> +</mime-info> Yeah it is weird but this is how you name it if the app installs the mime-type. I will however opt for the correct thing and add this to the shared mime database, see bug 'i filed here: https://bugs.freedesktop.org/show_bug.cgi?id=92654 So this patch should not go in
Created attachment 314015 [details] [review] Add and convert geojson-vt to GJS
Created attachment 314016 [details] [review] Add GeoJSONSource Add a Champlain::TileSource that creates tiles from a GeoJSON file. This is based on the geojson-vt library from Mapbox.
Created attachment 314017 [details] [review] mapView: Add openGeoJSON method
Created attachment 314018 [details] [review] mainWindow: Add drag and drop support for GeoJSON
Review of attachment 314015 [details] [review]: You forgot to delete the two "--sourcedir=$(srcdir)/geojson-vt" :D
Review of attachment 314017 [details] [review]: ::: src/mapView.js @@ +188,3 @@ + try { + this._annotationMarkerLayer.remove_all(); + let geoJSONSource = new GeoJSONSource.GeoJSONSource({ Two whitespace before the "=" @@ +192,3 @@ + mapView: this, + markerLayer: this._annotationMarkerLayer + }); Should we align this? (you know, "file: file," along the constructor and the rest aligned to "file: file,") @@ +203,3 @@ + this._gotoBBox(geoJSONSource.bbox); + } catch(e) { + geoJSONSource.parse(); _("Failed to parse GeoJSON: %s").format(e.message) @@ +213,3 @@ + } else { + this.view.connect('realize', + this._annotationSource = geoJSONSource; "realize" signal is deprecated [1], it doesn't talk about an alternative, but I think you should watch the "realized" property. Also, is there any guarantee that the view doesn't get unrealized and realized again? should we connect this only once? [1] https://developer.gnome.org/clutter/stable/ClutterActor.html#ClutterActor-realize
Review of attachment 314015 [details] [review]: I actually kept them since I use an alias in the xml-file later, is that not ok?
Review of attachment 314017 [details] [review]: Thanks Damian! ::: src/mapView.js @@ +188,3 @@ + try { + this._annotationMarkerLayer.remove_all(); + let geoJSONSource = new GeoJSONSource.GeoJSONSource({ Thx! @@ +192,3 @@ + mapView: this, + markerLayer: this._annotationMarkerLayer + }); No, I do not think we should. @@ +203,3 @@ + this._gotoBBox(geoJSONSource.bbox); + } catch(e) { + let msg = _("Failed to parse GeoJSON:" + e.message); I am not sure I want the message at all, will think on it, but if we do we could use that format. @@ +213,3 @@ + } else { + this.view.connect('realize', + this._openGeoJSONInternal.bind(this, file)); Yeah, I know, it is troublesome. I could watch the realized property I guess, sure. And yeah the view gets realized only once. This is fine imo.
Review of attachment 314016 [details] [review]: Some general comments. - In the parsing code we are using classic C-like for loops instead of forEach, for..in or for..of. - Wouldn't be easier to just throw an exception in _isValid when we find an invalid coordinate instead of deciding wether return false or true, since we are actually aborting on the first invalid coordinate we find. Also, doing that we can have more information about the error like "The coordinate [184.89, -58.8] is not valid". ::: src/geoJSONSource.js @@ +140,3 @@ + return true; + + case 'Point': Should we extend the bbox to the coordinates of the point and validate the coordinates as well? @@ +148,3 @@ + latitude: geometry.coordinates[1], + longitude: geometry.coordinates[0] + }); Alignment @@ +157,3 @@ + return true; + + case 'MultiPoint': Should we create repeated markers in multiple locations in this case? @@ +183,3 @@ + if (!root.geometries) + return false; + for (let i; i < root.geometries.length; i00) i00? I see the Swedish keyboards has the Plus near the 0 :D @@ +242,3 @@ + cr.lineTo(coord[0], coord[1]); + } + }); Maybe, just maybe, this is faster (not sure how faster :D) cr.moveTo(geometry[0][0], geometry[0][1]); for (let i = 1; i < geometry.length; i++) { cr.lineTo(geometry[i][0], geometry[i][1]); } @@ +245,3 @@ + }); + if (feature.type === TileFeature.POLYGON) + cr.closePath(); I'm a bit confused here, a feature in this case specify a collection of geometries of the same type, right (a collection of points, a collection of lines or a collection of polygons)? Should we close the path for every geometry in case we are processing polygons?
Review of attachment 314015 [details] [review]: ::: src/Makefile.am @@ +7,3 @@ $(shell $(GLIB_COMPILE_RESOURCES) \ --sourcedir=$(srcdir) \ + --sourcedir=$(srcdir)/geojson-vt \ Ah... I was thinking originally to have something like <file>geojsonvt/clip.js</file> in the XML.
Review of attachment 313958 [details] [review]: ::: src/Makefile.am @@ +15,3 @@ $(AM_V_GEN) $(GLIB_COMPILE_RESOURCES) \ --target=$@ \ + --sourcedir=$(srcdir)/geojson-vt \ Hm yeah I don't do that. But could you explain a bit why?
Review of attachment 313963 [details] [review]: ::: data/maps.xml @@ +6,3 @@ + <glob pattern="*.geo.json"/> + </mime-type> +</mime-info> Great!
Review of attachment 314016 [details] [review]: ::: src/geoJSONSource.js @@ +242,3 @@ + cr.lineTo(coord[0], coord[1]); + } + }); Yeah I was thinking about this as well. But mostly about having to re-construct a bunch of closures. I love the forEach-method, but I'm pretty sure a common for-loop is faster (and a for-of would be even cleaner as well). But yeah. I have no numbers and the cycles spent writing this reply might be more than this loop will ever consume.
Review of attachment 314016 [details] [review]: Thanks! ::: src/geoJSONSource.js @@ +140,3 @@ + return true; + + case 'Point': Not sure, I guess we might as well I've assumed all the time that the point should be naturally in other areas but there is nothing that really backs that claim up, so good catch. @@ +148,3 @@ + latitude: geometry.coordinates[1], + longitude: geometry.coordinates[0] + }); What alignment is that? I do not subscribe to aligning every paramter. @@ +157,3 @@ + return true; + + case 'MultiPoint': I do not know. We will have to think on it. The geojson spec is not that exhaustive. The properties.name that I use for Point is not standardised. I do not know what to use for MultiPoint or what a MultiPoint is. But maybe it should be many markers. Not sure this is used at all. Maybe leave as an improvement for later? @@ +183,3 @@ + if (!root.geometries) + return false; + for (let i; i < root.geometries.length; i00) It is :) http://www.www8-hp.com/h22175/SwedenStore/Html/Merch/Images/WZ972AA-UUW_2_1560x1144.jpg @@ +242,3 @@ + cr.lineTo(coord[0], coord[1]); + } + }); Ok with you guys if I leave it like this until we see that optimization is needed? @@ +245,3 @@ + }); + if (feature.type === TileFeature.POLYGON) + cr.closePath(); Not really, and I understand the confusion. Here the geometryes are no longer the geojson ones. But the vector-tile mapbox ones. The vt in geojson-vt is a conversion to vector tiles. And the features there have a type polygon, linestring or point. We should close after each feature in this case. If it is a POLYGON.
Created attachment 314042 [details] [review] Add geojson-vt from Mapbox Geojson-vt is A highly efficient JavaScript library for slicing GeoJSON data into vector tiles on the fly, primarily designed to enable rendering and interacting with large geospatial datasets on the browser side (without a server). https://github.com/mapbox/geojson-vt, see LICENSE for license.
Created attachment 314043 [details] [review] Add and convert geojson-vt to GJS
Created attachment 314044 [details] [review] Add GeoJSONSource Add a Champlain::TileSource that creates tiles from a GeoJSON file. This is based on the geojson-vt library from Mapbox.
Created attachment 314045 [details] [review] mapView: Add openGeoJSON method
Created attachment 314046 [details] [review] application: Handle open GeoJSON files
Created attachment 314047 [details] [review] mainWindow: Add drag and drop support for GeoJSON
Created attachment 314048 [details] [review] Add geojson-vt from Mapbox Geojson-vt is A highly efficient JavaScript library for slicing GeoJSON data into vector tiles on the fly, primarily designed to enable rendering and interacting with large geospatial datasets on the browser side (without a server). https://github.com/mapbox/geojson-vt, see LICENSE for license.
Created attachment 314049 [details] [review] Add and convert geojson-vt to GJS
Created attachment 314050 [details] [review] Add GeoJSONSource Add a Champlain::TileSource that creates tiles from a GeoJSON file. This is based on the geojson-vt library from Mapbox.
Created attachment 314051 [details] [review] mapView: Add openGeoJSON method
Created attachment 314052 [details] [review] application: Handle open GeoJSON files
Created attachment 314053 [details] [review] mainWindow: Add drag and drop support for GeoJSON
Created attachment 314056 [details] [review] Add geojson-vt from Mapbox Geojson-vt is A highly efficient JavaScript library for slicing GeoJSON data into vector tiles on the fly, primarily designed to enable rendering and interacting with large geospatial datasets on the browser side (without a server). https://github.com/mapbox/geojson-vt, see LICENSE for license.
Created attachment 314057 [details] [review] Add and convert geojson-vt to GJS
Created attachment 314058 [details] [review] Add GeoJSONSource Add a Champlain::TileSource that creates tiles from a GeoJSON file. This is based on the geojson-vt library from Mapbox.
Created attachment 314059 [details] [review] mapView: Add openGeoJSON method
Created attachment 314060 [details] [review] application: Handle open GeoJSON files
Created attachment 314061 [details] [review] mainWindow: Add drag and drop support for GeoJSON
Created attachment 314062 [details] [review] Maps can handle the GeoJSON mime-type
Review of attachment 314016 [details] [review]: ::: src/geoJSONSource.js @@ +148,3 @@ + latitude: geometry.coordinates[1], + longitude: geometry.coordinates[0] + }); Me neither... but I'm pretty sure that's the Maps code style we are using (the style used when you instantiated place and placeMarker variables few lines below). @@ +183,3 @@ + if (!root.geometries) + return false; + for (let i; i < root.geometries.length; i00) Oh, I thought it was something like: http://www.keyboardco.com/keyboard_images/filco_tenkeyless_swedish_keyboard_filco_2.jpg
Review of attachment 314016 [details] [review]: ::: src/geoJSONSource.js @@ +148,3 @@ + latitude: geometry.coordinates[1], + longitude: geometry.coordinates[0] + }); I use both, since I do not like long lines :)
Review of attachment 314016 [details] [review]: ::: src/geoJSONSource.js @@ +157,3 @@ + return true; + + case 'MultiPoint': MultiPoint is just several points. But yeah, the properties-object is free form and not standardised. @@ +242,3 @@ + cr.lineTo(coord[0], coord[1]); + } + }); Definitely. @@ +245,3 @@ + }); + if (feature.type === TileFeature.POLYGON) + cr.closePath(); Yep! I had to read the geojson-vt code to understand that it also converts to another format though.
Review of attachment 314056 [details] [review]: OK
Review of attachment 314057 [details] [review]: OK
Review of attachment 314058 [details] [review]: Some nits and a real comment. There are also some missing spaces before if- and switch-statements. But I'm going to try to clean all that up next week. ::: src/geoJSONSource.js @@ +92,3 @@ + if (!(-180 <= coordinate[0] && coordinate[0] <= 180) && + (-90 <= coordinate[1] && coordinate[1] <= 90)) { + throw new Error(_("invalid coordinate found")); With the negate this expression started to get messy and a mistake slipped in. (I understand that this is a consequence of trying to satisfy both me and Dámian :)) This is how I'd write the whole thing: _validate: function([lon, lat]) { if ((-180 <= lon && lon <= 180) && ( -90 <= lat && lat <= 90)) { return; } throw new Error(_("invalid coordinate found")); } Also, this will never work for projected coordinates, so perhaps we should just bail out earlier if the CRS is set to something other than the default projection? @@ +156,3 @@ + let placeMarker = new PlaceMarker.PlaceMarker({ place: place, + mapView: this._mapView }); + this._markerLayer.add_marker(placeMarker); break; @@ +174,3 @@ + root.features.forEach((function(feature) { + this._parseGeometry(feature.geometry, feature.properties); + }).bind(this)) Missing semicolon. @@ +178,3 @@ + + case 'Feature': + this._parseGeometry(root.geometry, root.properties); break;
Review of attachment 314059 [details] [review]: OK
Review of attachment 314060 [details] [review]: OK
Review of attachment 314061 [details] [review]: OK
Review of attachment 314062 [details] [review]: OK
Review of attachment 314058 [details] [review]: Thanks! ::: src/geoJSONSource.js @@ +92,3 @@ + if (!(-180 <= coordinate[0] && coordinate[0] <= 180) && + (-90 <= coordinate[1] && coordinate[1] <= 90)) { + throw new Error(_("invalid coordinate found")); Yeah I am aware of that. I think CRS awareness will be a later patch tho, if that is ok with you guys. Since it is a bit tricky. Since default projection can be expressed in different ways and I am not confident about it. So I wanted to handle it along with possible transformation code.
Created attachment 314114 [details] [review] Add GeoJSONSource Add a Champlain::TileSource that creates tiles from a GeoJSON file. This is based on the geojson-vt library from Mapbox.
Created attachment 314115 [details] [review] Add GeoJSONSource Add a Champlain::TileSource that creates tiles from a GeoJSON file. This is based on the geojson-vt library from Mapbox.
Created attachment 314118 [details] [review] Add GeoJSONSource Add a Champlain::TileSource that creates tiles from a GeoJSON file. This is based on the geojson-vt library from Mapbox.
Review of attachment 314056 [details] [review]: pushed
Review of attachment 314057 [details] [review]: pushed
Review of attachment 314059 [details] [review]: pushed
Review of attachment 314060 [details] [review]: pushed
Review of attachment 314061 [details] [review]: pushed
Review of attachment 314062 [details] [review]: pushed
Review of attachment 314118 [details] [review]: pushed with fixes
I think this bugreport should be renamed to "Adding geoJSON support" and then open a new one with KML/KMZ support. What do you think?
(In reply to tobias from comment #93) > I think this bugreport should be renamed to "Adding geoJSON support" and > then open a new one with KML/KMZ support. What do you think? Sounds reasonable! Thanks for keeping me in line Tobias!
https://bugzilla.gnome.org/show_bug.cgi?id=757171