[Qgis-developer] The future of OpenStreetMap plugin

[Even Rouault]

Le vendredi 01 février 2013 22:42:36, Martin Dobias a écrit :
> On Fri, Feb 1, 2013 at 9:11 AM,  <jr.morreale at enoreth.net> wrote:
> > Hi Martin,
> > 
> > Good to see this plugin is getting some love !
> > 
> > Le 2013-02-01 01:26, Martin Dobias a écrit :
> >> 2. instead of having a special provider, we could reuse an existing
> >> provider for viewing OSM layers - SpatiaLite seems to be the most
> >> viable candidate. Once data is imported from XML into a database, it
> >> should be possible to create one or more views (SpatiaLite tables) of
> >> the database (e.g. all polygons or linestrings with "highway" tag)
> > 
> > Did you had a look to the OGR driver made by Even Rouault ? The use of
> > PBF is possible (wayyyy smaller and faster to import) and the
> > performance are quite good when working on a big osm dataset.
> 
> I only know that it exists, I do not know much more about it. Compared
> to OGR support which only allows fetching of processed features, my
> approach is to allow also low-level access. With low level API you
> could access the underlying topology, fetch all tags of a node/way or
> access relations - I guess none of that is possible with OGR. It seems
> that the main use case for OGR is just to allow conversion to a
> different (more friendly) format.

Right, the low level concepts of OSM model are not exposed through the OGR 
API, because it doesn't have support for topology.

However you could "import" ogr/ogrsf_frmts/osm/osm_parser.h, 
ogr/ogrsf_frmts/osm/osm_parser.cpp and ogr/ogrsf_frmts/osm/gpb.h in QGIS in 
order to benefit from a parser that does the parsing of OSM XML and PBF in a 
transparent way from the user point of view. If you pursue that route, I'd 
suggest that you rename (or #define) the public symbols of 
ogr/ogrsf_frmts/osm/osm_parser.h so that they don't conflict with the ones of 
OGR (in case there are later changes in OGR for example)