in reply to OpenStreetMap API : Worker and Plugins architecture

You might get some mileage looking at the GDAL implementation of its OSM driver. https://www.gdal.org/drv_osm.html.

Alternately, the ogr2ogr utility can be used to convert the file to some other format (e.g. here) that you could parse more easily, but you can also read the data directly in perl using Geo::GDAL::FFI::Dataset (providing your GDAL is compiled with OSM support - I have not checked if it is by default).

  • Comment on Re: OpenStreetMap API : Worker and Plugins architecture

Replies are listed 'Best First'.
Re^2: OpenStreetMap API : Worker and Plugins architecture
by bliako (Abbot) on May 16, 2019 at 08:03 UTC

    I had something different in my mind: just a quick download of some terrain features, for some area, from the OSM website. But you, as I understand it, are suggesting that I download the full OSM data for an area, set up a database, import file into DB via GDAL and enquire DB using the set of tools provided by GDAL. Queries can be made also on the huge file downloaded but that's going to be slow depending on area size.

    Firstly, thanks for hinting - for the second time - about GDAL which this time, made me read a gentle introduction to it (in particular this one: https://medium.com/planet-stories/a-gentle-introduction-to-gdal-part-1-a3253eb96082).

    Secondly, don't you think that there is scope for what I am proposing if someone does not want to go the database way? For example, when one wants a quick way to search for say the traffic lights in an area in a script.

      I mentioned GDAL in case it is of use, as it covers a huge number of formats (and thus has a correspondingly large code base). You might be able to glean something from its source code for the OSM driver.

      A quick download of one feature type might be possible, but to be honest I've never tried either a full or partial download of these data (hence my answer did not have any code examples). If you do download all features for a region then you should not need to set up a database, though, as you can access the contents of the file directly using Geo::GDAL::FFI::Dataset and Geo::GDAL::FFI::Layer methods, including running SQL queries over the data (see ExecuteSQL in the Geo::GDAL::Dataset::Dataset docs). The Synopsis for Geo::GDAL::FFI has an example of how to load the data, copied below.

      I would definitely be interested in seeing something implemented in Perl to access these data, and can help with testing if you need it.

      # from the Geo::GDAL::FFI synopsis, # it should detect the file type automatically (untested) use Geo::GDAL::FFI qw/Open/; my $layer = Open('test.shp')->GetLayer; $layer->ResetReading; while (my $feature = $layer->GetNextFeature) { my $value = $feature->GetField('name'); my $geom = $feature->GetGeomField; say $value, ' ', $geom->AsText; }

        that's great thanks. I am currently working on what I proposed above but I see it being easily extended for including local files and DB (via GDAL). The main feature will be it operating on a higher level and via 3rd party plugins - in order to encourage independent development.

        I will let you know when I have something working, if you want to test it or have some suggestion about features. Thanks for your help.