[Qgis-user] QGIS Openstreetmap plugin

[Alex Mandel]

Yes SQLite/Spatialite implements almost all the same functions as other 
SQL databases. Spatialite has also has ST_ aliases to match most Postgis 
functions. So you could actually write your tool to use either.

QGIS ships spatialite libs, if you look on your toolbar, it's the 2nd 
one right next to Postgis. There are also a couple of plugins related to 
converting back and forth between the databases.

The plugin lives somewhere in the main source tree for QGIS. I looked 
around and can't really find where it is right now. However you should 
get on the developer mailing list and work with Martin.
See 
http://osgeo-org.1560.x6.nabble.com/The-future-of-OpenStreetMap-plugin-td5031372.html

Thanks,
Alex

On 05/18/2013 02:21 PM, Jo wrote:
> I must admit I don't know sqlite nor spatialite. Is it possible to create
> indexes, foreign key relations, stored procedures, triggers in it?
>
> I get the impression QGIS is already very much integrated with PostGIS, so
> for most people it shouldn't be a problem to install it. Once the
> connection is set up, all the rest can be scripted.
>
> I did have a look at the existing plugin and although I already noticed
> that the ways layer contains the nodes with tags and it seems to know what
> relations these nodes belong to, I can't seem to use the value of the
> rcn_ref tag for the label.
>
> Is the bug related to high node ids still in there? Can you point me to the
> source code of the plugin? Who knows, maybe I can fix that.
>
> Jo
>
> 2013/5/18 Stefan Keller <sfkeller at gmail.com>
>
>> Hi Polyglot
>>
>> Just to be sure I'd like to point to the existing OSM plugin for QGIS
>> [1], which deserves an evaluation and probably needs some care.
>>
>> Then, although I'm an active PostGIS (Postgres) supporter, I would
>> recommend Spatialite (SQLite) instead, given you use case.
>> It's more lightweight because it does not need a server installation
>> and you probably only use it as a temporary store.
>>
>> Yours, Stefan
>>
>>
>> [1] http://wiki.openstreetmap.org/wiki/QGIS_OSM_Plugin
>>
>> 2013/5/18 Jo <winfixit at gmail.com>:
>>> Hi,
>>>
>>> I'm a long time Openstreetmap contributor trying to wrap my brain around
>>> understanding how to work with QGIS. Quite likely this means I follow the
>>> opposite path of most.
>>>
>>> I managed to convert WFS to SHP, load that SHP in JOSM, the java
>>> openstreetmap editor and in PostGIS. Translating latin1 to UTF8 and
>>> Lambert72 to WGS84. Even , to . as the decimal operator.
>>>
>>> I also found how to style the data in the shape files.
>>>
>>> So far so good.
>>>
>>>
>>> Now I read the chapter in the manual on how to work with OSM data
>> directly
>>> in QGIS. What I'm missing is a way to work with the tags on the nodes
>> and a
>>> way to visualise route relations.
>>>
>>> The best way is probably to give a concrete example. We have cycle node
>>> networks. The nodes have rcn_ref tags, usually integers, sometimes START.
>>>
>>> The nodes are members in network relations.
>>>
>>> The ways between the nodes are members of route relations
>>>
>>> The route relations are also members of the network relations.
>>>
>>> I want the colour of the buffer around the nodes to be dependent on the
>>> network relation they belong to.
>>>
>>> I want the caption along the routes to come from the note tag of the
>> route
>>> relations. And I want to draw a buffer along their paths.
>>>
>>> Is there a way to access the tags of the relations and the nodes?
>>>
>>> Further down the line, I would love to be able to use QGIS to draw
>>> spiderlike network diagrams of public transportation networks. With ways
>>> coloured based on the bus lines passing there, 7 colours with an offset.
>>>
>>>
>>>
>>> At some point I may write a Python plugin myself to work with OSM data.
>> All
>>> the data would be stored in PostGIS. Only the nodes would have
>> geometries,
>>> which can be uploaded to the OSM server. Ways would have geometries.
>>> Relations would have geometries based on their type. But if ways or
>>> relations are changed the geometry gets updated at the nodes level. Then
>> all
>>> geometries which use those nodes will have to be recalculated (with a
>>> trigger function in PostGIS, I guess). I have no idea if such a solution
>>> would be able to scale. Especially as I would also like to store historic
>>> versions of the nodes, ways and relations in that DB.
>>>
>>> The nodes layer would show all the nodes, not only the ones which have no
>>> tags. Labels can be queried from the tags in the relations table as well
>>>
>>> The ways layer would show all the non closed ways, not sure about the
>>> roundabouts. Maybe all the ways which aren't areas.
>>>
>>> The polygons layer would show all the closed ways (areas) and the
>>> multipolygon relations. The buildings, the landuse, the boundaries.
>>>
>>> The routes layer would show all the route relations
>>>
>>>
>>> I have been giving this some thought:
>>>
>>> CREATE TABLE users
>>> (
>>>    userid integer PRIMARY KEY,
>>>    username text
>>> )
>>> WITH (
>>>    OIDS=FALSE
>>> );
>>> ALTER TABLE users
>>>    OWNER TO "Jo";
>>>
>>> CREATE TABLE changesets
>>> (
>>>    csid integer PRIMARY KEY,
>>>    cs_userid integer REFERENCES users,
>>>    csts timestamp
>>> )
>>> WITH (
>>>    OIDS=FALSE
>>> );
>>> ALTER TABLE changesets
>>>    OWNER TO "Jo";
>>>
>>> CREATE TABLE nodes
>>> (
>>>    nodeid bigint PRIMARY KEY,
>>>    nd_csid integer REFERENCES changesets,
>>>    ndversion integer,
>>>    --ndts timestamp,
>>>    geog geography
>>> )
>>> WITH (
>>>    OIDS=FALSE
>>> );
>>>
>>> CREATE TABLE ways
>>> (
>>>    wayid integer PRIMARY KEY,
>>>    wy_csid integer REFERENCES changesets,
>>>    wyversion integer
>>>    --wyts timestamp
>>> )
>>> WITH (
>>>    OIDS=FALSE
>>> );
>>>
>>> CREATE TABLE rels
>>> (
>>>    relid integer PRIMARY KEY,
>>>    rl_csid integer REFERENCES changesets,
>>>    rlversion integer
>>>    --rlts timestamp
>>> )
>>> WITH (
>>>    OIDS=FALSE
>>> );
>>>
>>> CREATE TABLE keys
>>> (
>>>    keyid bigserial PRIMARY KEY,
>>>    k text
>>> )
>>> WITH (
>>>    OIDS=FALSE
>>> );
>>> CREATE TABLE vals
>>> (
>>>    valueid bigserial PRIMARY KEY,
>>>    v text
>>> )
>>> WITH (
>>>    OIDS=FALSE
>>> );
>>> CREATE TABLE tags
>>> (
>>>    tagid bigserial PRIMARY KEY,
>>>    tg_nodeid bigint REFERENCES nodes,
>>>    tg_wayid bigint REFERENCES ways,
>>>    tg_relid bigint REFERENCES rels,
>>>    tg_keyid bigint REFERENCES keys,
>>>    tg_valueid bigint REFERENCES vals
>>> )
>>> WITH (
>>>    OIDS=FALSE
>>> );
>>>
>>> CREATE TABLE waynodes
>>> (
>>>    wnid bigserial PRIMARY KEY,
>>>    wn_way bigint REFERENCES ways,
>>>    wn_node bigint REFERENCES nodes
>>> )
>>> WITH (
>>>    OIDS=FALSE
>>> );
>>>
>>> CREATE TABLE relnodes
>>> (
>>>    rnid bigserial PRIMARY KEY,
>>>    rn_rel bigint REFERENCES rels,
>>>    rn_node bigint REFERENCES nodes
>>> )
>>> WITH (
>>>    OIDS=FALSE
>>> );
>>>
>>> CREATE TABLE relways
>>> (
>>>    rwid bigserial PRIMARY KEY,
>>>    rw_rel bigint REFERENCES rels,
>>>    rw_way bigint REFERENCES ways
>>> )
>>> WITH (
>>>    OIDS=FALSE
>>> );
>>>
>>> CREATE TABLE relrelations
>>> (
>>>    rrid bigserial PRIMARY KEY,
>>>    rr_parent bigint REFERENCES rels,
>>>    rr_child bigint REFERENCES rels
>>> )
>>> WITH (
>>>    OIDS=FALSE
>>> );
>>>
>>>
>>> Until now I was considering to program this as stored procedures in
>> PostGIS
>>> and with Python from the command line, but it may make a lot more sense
>> to
>>> write a QGIS plugin in Python.
>>>
>>> My goal is not only to be able to work with the data and visualise it. I
>>> also need to find a way to prepare open data, available as shape files
>> and
>>> WFS, for integration in Openstreetmap and subsequently to do quality
>> control
>>> on it and to assure we keep current with changes coming from upstream and
>>> the ability to create feedback reports on changes coming from the OSM
>>> contributors, once they are vetted as genuine.
>>>
>>> I'd love to hear your thoughts on all this. I wouldn't be surprised if
>>> there's something I didn't think about.
>>>
>>> Kind regards,
>>>
>>> Polyglot
>>>
>>> _______________________________________________
>>> Qgis-user mailing list
>>> Qgis-user at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>>>
>>
>
>
>
> _______________________________________________
> Qgis-user mailing list
> Qgis-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>