Provide support for exporting to GeoJSON about gpsbabel

[robertlipe]

I looked into this some time ago. Now that we have a Qt floor that includes
QJsonDocument (I think) the Points case would be super straight-forward and
a lovely starter project for someone wanting to get their feet wet. Tracks
and Routes would map to MultiLineStrings easily. There would be some
special casing for their weird handling at the antimeridian, but I'd bet we
could ship millions of copies before anyone noticed we got that wrong.

We don't really have concepts of Polygons and such. We could possibly
special case if first and end points were the same. We have a few formats
that have this concept (KML, shapefile) but it's not fundamental to us
given the "GPS" in "GPSBabel".

Anyone wanting to tackle this, please sign up.

On Thu, Sep 8, 2016 at 11:38 AM, Andre-John Mas [email protected]
wrote:

It would be useful to be able to export directly to GeoJSON. Currently I
need to convert to GPX and then with another application GPX to GeoJSON.
Having native GeoJSON would be useful.

GeoJSON is covered by RFC-7946 https://tools.ietf.org/html/rfc7946

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#53, or mute the thread
https://github.com/notifications/unsubscribe-auth/AIUh79St_CPj-WWLUI8c9DzNjO61aRaiks5qoDohgaJpZM4J4MxH
.

[GPSBabelDeveloper]

For waypoints, you can sort of see what this would look like with commit 4ce284a It probably doesn't validate, but the output for trivial waypoints (no alt) sure looks pretty GeoJSON-y. The serialization is probably not super memory efficient, but I'm not sure it has to be. Do you (or anyone else) want to run with it? My (scarce) nights and weekends are better devoted to fixing the problems in the 1.5.3 release I made in Jan (sigh) and rolling up the fixes to date over a feature requested by one user. There may have been a second, but this has been on my distant radar for a while...

[GPSBabelDeveloper]

Added in ecbf040 and a few fast-follow submits to fix issues with older Qt.

[HarelM]

What about conversion from GeoJson to other formats? I see that the tests in the above commit are only referring to GeoJson as Output...?
Since this was not supported when I started using GPSBabel I wrote it (in C#).
If this helps feel free to translate the code (conversion from GPX to GeoJson):
https://github.com/IsraelHikingMap/Site/blob/master/IsraelHiking.API/Converters/GpxGeoJsonConverter.cs
It uses LINQ and some C# specific operators (like ?? which is a null check + assignment) which reduces the amount of code a bit but the general idea is there.

[robertlipe]

The original request was for GeoJSON as an output. Adding it as an input would be a bit awkward as many of the data types don't map naturally into our data structures, but I'll review and integrate CLs from anyone so motivated. JSON in Qt isn't hard. http://doc.qt.io/qt-5/json.html If you understand GeoJSON well enough to care about this topic, you can probably stamp out a GeoJSON reader in GPSBabel.

…

On Tue, Jan 17, 2017 at 3:17 PM, Harel M ***@***.***> wrote: What about conversion from GeoJson to other formats? I see that the tests in the above commit are only referring to GeoJson as Output...? Since this was not supported when I started using GPSBabel I wrote it (in C#). If this helps feel free to translate the code (conversion from GPX to GeoJson): https://github.com/IsraelHikingMap/Site/blob/master/IsraelHiking.API/ Converters/GpxGeoJsonConverter.cs It uses LINQ and some C# specific operators (like ?? which is a null check + assignment) which reduces the amount of code a bit but the general idea is there. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIUh76robJovoZo1e0stlpF9tueTZgNmks5rTS_dgaJpZM4J4MxH> .

[HarelM]

I'll see if I can find the relevant C++ neurons.
Do you have a getting started readme for first compilation and coding conventions?
I work on windows.
Do you want me to open a new issue for geojson as input?

[robertlipe]

https://www.gpsbabel.org/htmldoc-development/Source.html is a bit dated. On Windows, QtCreator is probably the way to go on Windows. We have rather few Windows devs, but it's what I used to build the last few Windows releases so the *.pro builds should be reasonably up to date. Skimming https://github.com/gpsbabel/gpsbabel/blob/master/format_skeleton.cc gives you an idea of the callbacks. It's really not very C++-like - it shows that it began life as a C project. The fundamental structures are all in defs.h - for readers, you create a new waypoint, populate all the members you can learn and either pass it to waypt_add() or you call route_head_alloc(), add waypoints to it, and then pass the resulting route to either route_add_head or track_add_head. (Yes, the naming is all inconsistent.) geojson.cc already has bodies for geojson_rd_init, geojson_rd_deinit, and geojson_read - you just need to fill them in and tweak the entries in geojson_vecs to make it work. Looking at other XML readers, we have geo.cc, gpx.cc, mapfactor.cc, navicache.cc, and xmlgeneric.cc for examples. mapfactor and navicache are probably the simplest. geo, gpx, and kml are all strongly influenced by our old "raw" expat design and build and tear down a string that represents the tag tree and does string compares. The GPX reader is highly optimized for performance, building a perfect hash on the tag tree so that a fast switch can be done on the tags. Doing it from scratch in QtXmlStreamReader, it would probably loook very different. If you've ever worked with a SAX-style reader, you'll find the event stream very familiar. http://doc.qt.io/qt-4.8/qxmlstreamreader.html There are things in GeoJSON that are just a bad fit for us. If you choose to make the reader read a LinearRing as a track (which wouldn't be totally unreasonable) and then write it back as GeoJSON, it's going to be a LineString when it comes out. We have similar impedance mismatches with KML and some other GIS-influenced formats. As for code style, try to match what's around it. My style has been evolving over time from AT&T style more to match Google's C++ style and clang-format is my goto when things get ugly.

…

On Thu, Jan 19, 2017 at 12:47 PM, Harel M ***@***.***> wrote: I'll see if I can find the relevant C++ neurons. Do you have a getting started readme for first compilation and coding conventions? I work on windows. Do you want me to open a new issue for geojson as input? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIUh78GUM89UMEICapLcqpOZ7JPQUTY1ks5rT6-7gaJpZM4J4MxH> .

[HarelM]

Thanks for the intro. I'll try to setup the environment and compile the code, we'll see how it goes from there.
Let me know if you want me to create a windows developer getting started manual (I can add it to the readme.md file if you'd like).
Assuming I'll be able to make it work will the next official release will only be a year from now?

[robertlipe]

There isn't a fixed schedule, though the last two have had a pretty obvious pattern. The reality is that we've reached stasis for the millions. Releases on all the OSes that have reasonable testing, packaging, doc, web support, etc. cost me a couple of dozen hours to create. When I get maybe ten (maybe) submits a year that'll benefit more than a few dozen users, I tend to clump releases around the holidays when I have time. If we had a hundred programmers checking things in that'd benefit a thousand users each and I could be release manager instead of tech support, we'd probably see more releases. We don't. I'm fifteen plus years into this with tens (hundreds?) of millions of users and just no longer believe that there are thousands of people willing to work on things for free. So I do my best to encourage enthusiastic contributors, support our installed base, and still squirt out a release zip/exe/tarball/tag every now and then. Let's get perspective, we run about 500 downloads a day and you're like the fourth person to show any interest in GeoJSON; the first was in 2009. I've always aggressively pushed to source master - anyone wanting bleeding edge has always been able to get it from CVS/SVN/Git. Now that most of the geo world has circled around GPX (which I was also involved in...) for basic waypoint/track transfer, our usage has plummeted. We have crazy filters and fancy stuff, but our usage has fallen many, many points in the last ten years. I can see it in ad revenue, page views, posts on the lists, code contributions, etc. and they're all following a prett consistent curve trending down: geo-stuff is just less interesting than it was ten years ago.

…

On Thu, Jan 19, 2017 at 3:36 PM, Harel M ***@***.***> wrote: Thanks for the intro. I'll try to setup the environment and compile the code, we'll see how it goes from there. Let me know if you want me to create a windows developer getting started manual (I can add it to the readme.md file if you'd like). Assuming I'll be able to make it work will the next official release will only be a year from now? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIUh7zp_PGx3ZvBNUvf3ngHFkFLNHhuvks5rT9dvgaJpZM4J4MxH> .

[HarelM]

I think geo-stuff is very interesting, I don't think people are less interested in it.
I just think in terms of standards - companies and developers understand now (as opposed to ten years ago) that you don't need to invent the wheel every time you write a program (especially when you want to pass data from one program to the other) - just take something that is a standard and use it.
I use GPSBabel in my site in order to be able to support legacy format, but the output is always GPX, standard, not interest (IMHO).
To be more practical, I tried to compile the project on my PC and got the following error:

11:57:27: Running steps for project GPSBabel...
11:57:27: Starting: "C:\Qt\5.8\msvc2015_64\bin\qmake.exe" D:\Github\GPSBabel\GPSBabel.pro -spec win32-msvc2015 "CONFIG+=debug" "CONFIG+=qml_debug"
11:57:27: The process "C:\Qt\5.8\msvc2015_64\bin\qmake.exe" exited normally.
11:57:27: Starting: "C:\Qt\Tools\QtCreator\bin\jom.exe" qmake_all
Error: File Makefile doesn't exist.
11:57:27: The process "C:\Qt\Tools\QtCreator\bin\jom.exe" exited with code 2.
Error while building/deploying project GPSBabel (kit: Desktop Qt 5.8.0 MSVC2015_64bit)
The kit Desktop Qt 5.8.0 MSVC2015_64bit has configuration issues which might be the root cause for this problem.
When executing step "qmake"
11:57:28: Elapsed time: 00:01.

As I said, I'm new to Qt and I'm not sure how to solve this one, googling didn't help much and my c/c++ skills were around visual studio which does all the hard work behind the scenes so I'm not very good with all the makefiles etc... (Last time I used it was in the university, around 8 years ago...)
I also needed to add goejson.cc to the pro file but that was not a real problem, although the way the IDE did it was different than what's currently written, which is weird IMO.

[HarelM]

Well, it seems that the failed compilation above creates a cxproj file I can use with visual studio to compile. unfortunately, ftruncate in mtk_logger.cc is unix specific function... :-( has this project was successfully built lately on windows?

[GPSBabelDeveloper]

I fixed that when I made the release. Git status and git diff don't show it outstanding, but I don't see it in the web version online, so I probably lost it in git somehow. I'm sure it's my fault, but I *hate* how easy it is to lose work in git. #if __WIN32__ _chsize(fileno(dout), addr_max); #else ftruncate(fileno(dout), addr_max); #endif

…

On Sun, Jan 22, 2017 at 3:42 PM, Harel M ***@***.***> wrote: Well, it seems that the failed compilation above creates a cxproj file I can use with visual studio to compile. unfortunately, ftruncate in mtk_logger.cc is unix specific function... :-( has this project was successfully built lately on windows? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALdQD5lV8OI-KzHe4skINLsdn7UiPijGks5rU81XgaJpZM4J4MxH> .

[robertlipe]

Ugh, it's on a branch. 269c55e#diff-96cb48781d1bab9aa2f251feddd6a559 has the full change. Honestly, if you're not working on the mtk_logger, just comment that line out and move on.

…

On Sun, Jan 22, 2017 at 4:25 PM, GPSBabel ***@***.***> wrote: I fixed that when I made the release. Git status and git diff don't show it outstanding, but I don't see it in the web version online, so I probably lost it in git somehow. I'm sure it's my fault, but I *hate* how easy it is to lose work in git. #if __WIN32__ _chsize(fileno(dout), addr_max); #else ftruncate(fileno(dout), addr_max); #endif On Sun, Jan 22, 2017 at 3:42 PM, Harel M ***@***.***> wrote: > Well, it seems that the failed compilation above creates a cxproj file I > can use with visual studio to compile. unfortunately, ftruncate in > mtk_logger.cc is unix specific function... :-( has this project was > successfully built lately on windows? > > — > You are receiving this because you modified the open/close state. > Reply to this email directly, view it on GitHub > <#53 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ALdQD5lV8OI- KzHe4skINLsdn7UiPijGks5rU81XgaJpZM4J4MxH> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIUh73kUq--FmrCGzlPT17jRmYjnSeUYks5rU9dTgaJpZM4J4MxH> .

[HarelM]

made it work with the following lines:

#ifdef __WIN32__
#include <io.h>
#define ftruncate _chsize
#endif

I managed to compile it and run it only on debug. break point is hitting, finally to the interesting part... :-)

[HarelM]

There's a sln file and vcxproj file, but they seem to be old, do you want me to replace them when I check-in my code or do you want the qmake should do the hard work, there are some things that are misconfigured there like the win8.0 sdk.