Re: [OSM-talk-be] Importing Villo! API data

[Marc Gemis]

I'm not sure whether it is a good idea to "copy" the address of a
house to another object, that does not really have that address.
As the original address information is "face 35-39 / tegenover 35-39",
the bicycle rental place should not have addr:housenumber=35-39 imho


m.

On Sun, Oct 15, 2017 at 6:57 PM, Yves bxl-forever
 wrote:
> Hello,
>
> In the past weeks I have also wanted to do some cleanup on Villo! stations 
> and it’s a fact that there still quite a lot of work to be done.
>
> Just a few thoughts about the idea of bulk data imports because this is what 
> gave us really "ugly" nodes sometimes.
>
> The name itself is a problem because what they present as the name is 
> actually a string that concatenates the ID of the station, the name and its 
> address.  This is why tagging this as "official_name" does not seem to make 
> any sense.
>
> Their JSON dataset usually looks like this:
>
> "name":"076 - PLACE VAN MEENEN/VAN MEENENPLEIN",
> "address":"PLACE VAN MEENEN/VAN MEENENPLEIN - AV PAUL DEJAER (FACE 35 - 39) / 
> PAUL DEJAERLAAN (TEGENOVER 35 - 39)"
>
>
> And we must translate it as such in our OSM nodes:
>
> ref=76
> name="Place Van Meenen - Van Meenenplein"
> name:fr="Place Van Meenen"
> name:nl="Van Meenenplein"
> addr:street="Place Maurice Van Meenen - Maurice Van Meenenplein"
> addr:housenumber="35-39"
>
>
> It’s probably feasible to parse the fields automatically and make something 
> that looks clean.
> But I am not sure that the street name will always match (see example here, 
> official name has "Maurice" somewhere and our parsing script will not guess 
> it unless you feed it with a list of all streets).
>
> About missing names in one language, this is tricky: normally we should stick 
> with the official name given by the operator.  But another approach will be 
> that if we know of an official translation (because it is the same name as 
> the street or even a bus stop nearby, or a building) it should be used.  And 
> I agree that we should fix typos without asking, like in your example.
>
> Another problem is that the longitude and latitude fields must be checked to 
> avoid putting stations in the middle of an intersection or inside a building.
>
>
> In summary, I will recommend a safer approach, i.e. extracting a list of 
> missing stations, and add them one by one manually, after checking whether 
> the data looks fine.
> But it will be nice to hear the thoughts of other members of the community.
>
> Have a nice day.
>
> Yves
>
>
>
> On Sun, 15 Oct 2017 13:48:42 +0200
> CedB12  wrote:
>
>> Hello all,
>>
>> Lately I have been looking at the Villo! dataset from the JCDecaux API
>> at [1], which is released under the Etalab Open License (see also [2]).
>> I want to consult the community about the use of this data to improve
>> the tagging of the stations we have already mapped. I would also like to
>> discuss a potential import of the hundred or so stations that are
>> reported in the API but have not been mapped yet in OSM.
>>
>> My priority is to fix the tagging of station names and reference
>> numbers, which are often wrong or missing in the already-mapped
>> stations. I am aware of a few quality issues in the names reported by
>> the API (which, as far as I know, are actually the names reported at the
>> stations themselves), so this cannot be a fully automated process. As
>> far as ref tags are concerned, only 25 existing station nodes do not
>> match the API. I have not pushed any change yet in case this thread
>> brings up an objection to the use of this API data.
>>
>> More importantly, given the quality issues in the API names, we would
>> need to discuss how exactly we want to tag names vs. what the "official"
>> names are.
>>
>> To give you a quick example of what kind of problems we can find in the
>> API, consider that one station is named "342 - MAISON COMMUNALE DE
>> BERCHEM ST AGHATE". Like all other stations, the name is in all-caps.
>> This one in particular contains a misspelling: the commune is actually
>> spelled "Berchem-Ste-Agathe". Also, unlike other stations, this one has
>> no official Dutch name, and it is not clear to me whether we should
>> provide our own translation in the name and name:nl tags.
>>
>> I actually got a little bit ahead of myself and had prepared a diary
>> entry draft as well as a more detailed and specific email for this
>> mailing list, but I now realize that unloading all of this at once might
>> have felt a bit forceful. So before I go into the details of all the
>> quirks in the API data and formulate a general proposal for tagging, I
>> wanted to take a more open-ended approach and ask if anyone had anything
>> to share regarding our mapping and tagging of Villo! stations. I am also
>> interested in your thoughts on how we should tag the station I gave
>> above as an example (in terms of name, name:fr, name:nl, and maybe other
>> kinds of name tags like official_name).
>>
>> But before that, I would like to make sure that it

Re: [OSM-talk-be] Meetup about rendering of maps

[Marc Ducobu]

Hello,

Two years ago I created a map with QGIS & OSM. You can find the QGIS style
there : https://github.com/Champs-Libres/QGIS-OSM-styles

I explained the method is a blog-post (
http://blog.champs-libres.coop/carto/2015/04/10/creer-une-carte-cycliste-avec-osm-et-qgis.html
). I took some inspiration from
https://anitagraser.com/2014/05/31/a-guide-to-googlemaps-like-maps-with-osm-in-qgis/
& https://www.youtube.com/watch?v=Zsf4OxUDS44

Have a nice evening.

Marc

On 10 October 2017 at 18:04, joost schouppe 
wrote:

> I set up a repo a couple of days ago. I've now added you, Jo.
>
> This is the URL:
> https://github.com/osmbe/qgis_rendering
>
> I use sqlite databases (which behave like files) in QGIS, and they behave
> just fine.
>
> 2017-10-09 14:45 GMT+02:00 Jo :
>
>> Yes, we can look into github on Wednesday evening. Joost, please set up a
>> repo for it.
>>
>> OK, so with a bit of luck we have Clem to show Maperitive and Pieter to
>> show QGIS for rendering.
>>
>> Yesterday I started watching this series:
>> https://www.youtube.com/playlist?list=PL7HotvlLKHCs9nD1fFUjSOsZrsnctyV2R
>>
>> This explains it quite succinctly, but putting it into practice is still
>> a challenge with QGIS. Mine crashes a lot. Now I'm thinking it would be
>> better if I would involve PostGIS, instead of working with files, for a
>> larger region.
>>
>> Somehow Maperitive was able to cope with it, but there my problem is
>> automating the workflow to get consistent results.
>>
>> Jo
>>
>> 2017-10-05 11:06 GMT+02:00 Pieter Brusselman <
>> pieter.brussel...@tragewegen.be>:
>>
>>> @Joost,
>>>
>>> OK, you can do that.  But I need a short intro in Github.  Maybe
>>> wendsday evening?
>>>
>>>
>>> Pieter Brusselman
>>> *Cartografie ~ Projectmedewerker*
>>>
>>> [image: (logo boompja)] 
>>>
>>> *A* Kasteellaan 349
>>>  A,
>>> 9000 Gent
>>> *T* 09 / 331 59 27
>>> *W *www.tragewegen.be
>>>
>>> [image: logo facebook] 
>>>
>>> ter info: ik werk niet op vrijdag
>>> Op 5/10/2017 om 10:48 schreef joost schouppe:
>>>
>>> Pieter,
>>>
>>> I could make a repository on our github page https://github.com/osmbe/
>>> for a QGIS project if you're interested.
>>>
>>> 2017-10-05 10:22 GMT+02:00 Jo :
>>>
 Hey, that is great news! I will also come to FOSS4G the day after our
 Meetup. Somebody who uses Maperitive to render maps for the GR guides will
 probably also join us on Wednesday evening.

 Jo

 2017-10-05 9:33 GMT+02:00 Pieter Brusselman <
 pieter.brussel...@tragewegen.be>:

> Hi,
>
> The last year we (trage wegen vzw) made a lot of maps based on
> OSM-data using QGIS.  On octobre 26th we give a talk about this on FOSS4G.
> But I like to come to the meeting to talk about this and sharing 
> experience
> (and stylsheets :-))
>
> Grtz,
> Pieter
>
> Pieter Brusselman
> *Cartografie ~ Projectmedewerker*
>
> [image: (logo boompja)] 
>
> *A* Kasteellaan 349
>  A,
> 9000 Gent
> *T* 09 / 331 59 27
> *W *www.tragewegen.be
>
> [image: logo facebook] 
>
> ter info: ik werk niet op vrijdag
> Op 5/10/2017 om 9:11 schreef joost schouppe:
>
> I like to use QGIS for basic stuff. E.g. use an open layers background
> map, and some data on top of that to highlight certain details. E.g. the
> maps in this diary were made with OSM data queried from overpass and some
> open layers map: http://www.openstreetmap.
> org/user/joost%20schouppe/diary/38103
>
> It's also relativly easy to use QGIS for rendering OSM data using a
> sqlite database (and that's easy to make within the package, based on a
> .pbf file). I don't have experience making a pretty map that way, but it
> can be quite useful to make maps highlighting specific kinds of data. E.g.
> maps like these are easy to make in QGIS: http://www.openstreetmap
> .org/user/joost%20schouppe/diary/40267
> (though here the data comes from the osm-history toolchain, not just
> from a pbf file)
>
> I think theoretically you could use QGIS and a stylesheet to make a
> pretty map from scratch, but haven't seen an example yet. And someone has
> been working for years on doing something similar in ArcGIS, and I don't
> think he released it yet.
>
> 2017-10-05 8:17 GMT+02:00 Jo :
>
>> Hi,
>>
>> During the next Leuven Monthly OSM Meetup I would like to discuss
>> rendering. I was using Maperitive in the past to create this:
>>
>> https://upload.wikimedia.org/wikipedia/commons/a/a2/Pad_van_
>> Ad_op_OSM.png
>>
>> I know. I should update that map more regularly...
>>
>> Would it make sense to try and use QGIS for ren

Re: [OSM-talk-be] http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Walking_Routes

[Wouter Hamelinck]

I agree that the page is getting huge. The three page suggestion looks OK
to me. It is probably best to keep a general page that basically links to
the three new pages.
Short remark about the nordic walking routes: when I added the table of the
routes in Viroinval, I did it on the walking routes page because creating a
new page for nordic walking seemed like overkill.  If we are splitting the
page, it might be worth considering to create a separate page for nordic
walking routes. But apart from the Vironval network, I am personally not
aware of other specific routes. If there are others, I would be in favour
of a separate page. If those in Viroinval are the only ones, I would rather
keep them on the walking page.

wouter


On Sat, Oct 14, 2017 at 6:03 PM, joost schouppe 
wrote:

> Hi Stijn,
>
> That is a huge page!
>
> I would suggest splitting it in three:
>
> - long distance routes
>
> - walking node networks
>
> - local routes
>
>
>
> 2017-10-03 20:20 GMT+02:00 Stijn Rombauts :
>
>> Hello,
>>
>> Could it be that this page [1] has become too big, with too many links to
>> relations? I hope you see what I see: from the 5th relation in the Nordic
>> Walking table all relations are replaced by a Template:Relation.
>> If so, what are we going to do about it? Split it up? In how many pages?
>>
>> Regards,
>>
>> StijnRR
>>
>> [1] http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Walki
>> ng_Routes#Nordic_Walking
>>
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>
>
> --
> Joost Schouppe
> OpenStreetMap  |
> Twitter  | LinkedIn
>  | Meetup
> 
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>


-- 
"Den som ikke tror på seg selv kommer ingen vei."
   - Thor Heyerdahl
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Importing Villo! API data

[Yves bxl-forever]

Hello,

In the past weeks I have also wanted to do some cleanup on Villo! stations and 
it’s a fact that there still quite a lot of work to be done.

Just a few thoughts about the idea of bulk data imports because this is what 
gave us really "ugly" nodes sometimes.

The name itself is a problem because what they present as the name is actually 
a string that concatenates the ID of the station, the name and its address.  
This is why tagging this as "official_name" does not seem to make any sense.

Their JSON dataset usually looks like this:

"name":"076 - PLACE VAN MEENEN/VAN MEENENPLEIN",
"address":"PLACE VAN MEENEN/VAN MEENENPLEIN - AV PAUL DEJAER (FACE 35 - 39) / 
PAUL DEJAERLAAN (TEGENOVER 35 - 39)"


And we must translate it as such in our OSM nodes:

ref=76
name="Place Van Meenen - Van Meenenplein"
name:fr="Place Van Meenen"
name:nl="Van Meenenplein"
addr:street="Place Maurice Van Meenen - Maurice Van Meenenplein"
addr:housenumber="35-39"


It’s probably feasible to parse the fields automatically and make something 
that looks clean.
But I am not sure that the street name will always match (see example here, 
official name has "Maurice" somewhere and our parsing script will not guess it 
unless you feed it with a list of all streets).

About missing names in one language, this is tricky: normally we should stick 
with the official name given by the operator.  But another approach will be 
that if we know of an official translation (because it is the same name as the 
street or even a bus stop nearby, or a building) it should be used.  And I 
agree that we should fix typos without asking, like in your example.

Another problem is that the longitude and latitude fields must be checked to 
avoid putting stations in the middle of an intersection or inside a building.


In summary, I will recommend a safer approach, i.e. extracting a list of 
missing stations, and add them one by one manually, after checking whether the 
data looks fine.
But it will be nice to hear the thoughts of other members of the community.

Have a nice day.

Yves



On Sun, 15 Oct 2017 13:48:42 +0200
CedB12  wrote:

> Hello all,
> 
> Lately I have been looking at the Villo! dataset from the JCDecaux API
> at [1], which is released under the Etalab Open License (see also [2]).
> I want to consult the community about the use of this data to improve
> the tagging of the stations we have already mapped. I would also like to
> discuss a potential import of the hundred or so stations that are
> reported in the API but have not been mapped yet in OSM.
> 
> My priority is to fix the tagging of station names and reference
> numbers, which are often wrong or missing in the already-mapped
> stations. I am aware of a few quality issues in the names reported by
> the API (which, as far as I know, are actually the names reported at the
> stations themselves), so this cannot be a fully automated process. As
> far as ref tags are concerned, only 25 existing station nodes do not
> match the API. I have not pushed any change yet in case this thread
> brings up an objection to the use of this API data.
> 
> More importantly, given the quality issues in the API names, we would
> need to discuss how exactly we want to tag names vs. what the "official"
> names are.
> 
> To give you a quick example of what kind of problems we can find in the
> API, consider that one station is named "342 - MAISON COMMUNALE DE
> BERCHEM ST AGHATE". Like all other stations, the name is in all-caps.
> This one in particular contains a misspelling: the commune is actually
> spelled "Berchem-Ste-Agathe". Also, unlike other stations, this one has
> no official Dutch name, and it is not clear to me whether we should
> provide our own translation in the name and name:nl tags.
> 
> I actually got a little bit ahead of myself and had prepared a diary
> entry draft as well as a more detailed and specific email for this
> mailing list, but I now realize that unloading all of this at once might
> have felt a bit forceful. So before I go into the details of all the
> quirks in the API data and formulate a general proposal for tagging, I
> wanted to take a more open-ended approach and ask if anyone had anything
> to share regarding our mapping and tagging of Villo! stations. I am also
> interested in your thoughts on how we should tag the station I gave
> above as an example (in terms of name, name:fr, name:nl, and maybe other
> kinds of name tags like official_name).
> 
> But before that, I would like to make sure that it is OK to import
> Etalab-licensed data, because otherwise this effort will be pointless. I
> assume it must be fine because the license states to be compatible with
> "any licence which requires at least the attribution of the «
> Information »" [3], including the Open Government License which is in
> turn listed on the OSM wiki page on ODbL compatibility [4]. How are the
> requirements of the license (attribution by source name + date + URL)
> handled, though?
> 
> 

[OSM-talk-be] Importing Villo! API data

[CedB12]

Hello all,

Lately I have been looking at the Villo! dataset from the JCDecaux API
at [1], which is released under the Etalab Open License (see also [2]).
I want to consult the community about the use of this data to improve
the tagging of the stations we have already mapped. I would also like to
discuss a potential import of the hundred or so stations that are
reported in the API but have not been mapped yet in OSM.

My priority is to fix the tagging of station names and reference
numbers, which are often wrong or missing in the already-mapped
stations. I am aware of a few quality issues in the names reported by
the API (which, as far as I know, are actually the names reported at the
stations themselves), so this cannot be a fully automated process. As
far as ref tags are concerned, only 25 existing station nodes do not
match the API. I have not pushed any change yet in case this thread
brings up an objection to the use of this API data.

More importantly, given the quality issues in the API names, we would
need to discuss how exactly we want to tag names vs. what the "official"
names are.

To give you a quick example of what kind of problems we can find in the
API, consider that one station is named "342 - MAISON COMMUNALE DE
BERCHEM ST AGHATE". Like all other stations, the name is in all-caps.
This one in particular contains a misspelling: the commune is actually
spelled "Berchem-Ste-Agathe". Also, unlike other stations, this one has
no official Dutch name, and it is not clear to me whether we should
provide our own translation in the name and name:nl tags.

I actually got a little bit ahead of myself and had prepared a diary
entry draft as well as a more detailed and specific email for this
mailing list, but I now realize that unloading all of this at once might
have felt a bit forceful. So before I go into the details of all the
quirks in the API data and formulate a general proposal for tagging, I
wanted to take a more open-ended approach and ask if anyone had anything
to share regarding our mapping and tagging of Villo! stations. I am also
interested in your thoughts on how we should tag the station I gave
above as an example (in terms of name, name:fr, name:nl, and maybe other
kinds of name tags like official_name).

But before that, I would like to make sure that it is OK to import
Etalab-licensed data, because otherwise this effort will be pointless. I
assume it must be fine because the license states to be compatible with
"any licence which requires at least the attribution of the «
Information »" [3], including the Open Government License which is in
turn listed on the OSM wiki page on ODbL compatibility [4]. How are the
requirements of the license (attribution by source name + date + URL)
handled, though?

Also, does an operation of this scale (tagging a subset of 200 existing
nodes and possibly importing another 100) require that I follow the
import guidelines?

Thanks,

Cédric


[1] https://developer.jcdecaux.com/
[2] http://opendatastore.brussels/en/dataset/villo
[3] https://developer.jcdecaux.com/files/Open-Licence-en.pdf
[4] https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be