Re: [OSM-talk-be] Fwd: Re: tagging conventions

[Marc Gemis]

On Mon, Jan 4, 2021 at 8:02 PM EeBie  wrote:

>
> In that way they look as quality roads on the map and not as tracks.
>
>>
>>>
BTW, this is mapping for the renderer (or a particular renderer) and is bad
practice.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Vernielde uitkijktoren

[Marc Gemis]

De huidige tag aanpassen naar disused:=
Dus bv. disused:man_made=tower
eventueel aanvullen met ruins=yes

mvg

m

On Sun, Aug 16, 2020 at 7:12 PM TrailGhost via Talk-be
 wrote:
>
> Gegroet OSM,
>
> Na een tijdje niet meer op OpenStreetMap geweest te zijn toch maar opnieuw 
> een account aangemaakt en al onmiddellijk een vraag.
> - Ben onderweg een uitkijktoren tegengekomen maar die is volledig ingestort. 
> Hoe pas ik dit aan in OSM? Verwijder de toren? Momenteel heb ik er een 
> commentaar bijgezet dat de toren niet meer toegankelijk is.
>
> Alvast bedankt voor de hulp en keep up the good work.
>
> TrailGhost
>
> PS: If anyone needs the message in English feel free to contact me.
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] privacy ed

[Marc Gemis]

According to 
https://www.gegevensbeschermingsautoriteit.be/recht-op-afbeelding-de-privacywet-algemeen,

"Toch geldt de Privacywet niet altijd. Beelden voor louter
persoonlijke of huishoudelijke doeleinden, zoals een familiealbum
aanleggen of privéopnames maken bij een sportmanifestatie, is de
wetgeving niet van toepassing. Wanneer die beelden op het internet
worden gezet, overstijgt dit de persoonlijke of huishoudelijke
doeleinden omdat de beelden verstrekt worden aan een onbeperkt aantal
personen, waardoor de Privacywet wel van toepassing is."

So IMHO you can still take a picture of a street with people, go home,
map whatever you see on the picture and delete it (or keep it in or
personal archive). The privacy law is not applicable then.
My idea is that the focus of the photo is not on the people, but on
the environment when one makes photos for mapping purposes.

m.

On Sat, May 16, 2020 at 12:55 PM Midgard  wrote:
>
> On Fri, May 15, 2020, 19:38 Marc Gemis  wrote:
> > Taking pictures of people is not a problem, it's what you do with them
> > afterwards that is important.
> Op vr 15 mei 2020 22:51 schreef Sander Deryckere :
> > Taking a picture is usually not illegal indeed.
>
> No! You need prior permission to take a photo of a person.
> Being in a public place can be interpreted as silent permission for appearing 
> incidentally in
> overview photos.
>
> https://www.gegevensbeschermingsautoriteit.be/recht-op-afbeelding
> https://www.autoriteprotectiondonnees.be/droit-image
>
>
> Quoting Marc Gemis (2020-05-15 23:31:16)
> > Afaik,  Belgium changed the law  one or two years ago and you can now
> > publish pictures of art and buildings without problems.
>
> With some restrictions:
> https://nl.wikipedia.org/wiki/Panoramavrijheid#Belgi%C3%AB
> https://fr.wikipedia.org/wiki/Libert%C3%A9_de_panorama#En_Belgique
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] privacy ed

[Marc Gemis]

Afaik,  Belgium changed the law  one or two years ago and you can now
publish pictures of art and buildings without problems.  Wikimedia changed
its policy for such pictures at that moment

m

Op vr 15 mei 2020 22:51 schreef Sander Deryckere :

> Taking a picture is usually not illegal indeed. But sharing it in many
> cases is. Next to the privacy regulations already mentioned, people can ask
> to take pictures of their property offline on Google Streetview.
>
> Google certainly has a good legal team, and blurring those pictures does
> cost some money. So there must be a good reason why they comply to the
> request (as opposed to blurring of areal imagery of military sites, which
> they refused for many years).
>
> And in Belgium, most buildings even have copyright on them: the architect
> who designed the building had complete copyright, including on any pictures
> taken from the roadside. A famous example of this is that spreading
> pictures of the Atomium is forbidden without paying a license fee.
>
> Luckily, most of these laws require the "victim" to request to take it
> offline. Certainly if you make no money from it, it's very unlikely this
> will have legal consequences. If there are legal consequences, they're even
> more likely for the platform hosting the images instead of the uploader.
>
> So if you just use common sense and blur faces and license plates,
> everything should be ok.
>
> Op vr 15 mei 2020 20:33 schreef Jo :
>
>> Not only their faces, also license plates. And if you're doing it
>> manually maybe also stickers with recognisable information.
>>
>> Jo
>>
>> On Fri, May 15, 2020, 19:38 Marc Gemis  wrote:
>>
>>> Hello,
>>>
>>> I see no difference between contributing to OpenStreetMap via JOSM and
>>> iD or StreetComplete.
>>> Mapping a house, street, waste bin, etc. will not break any privacy.
>>> We do not map the names of the inhabitants of a house. Mapping items
>>> from someone's garden based on aerial imagery might be on the
>>> borderline of what is allowed. However, I do map sheds, ponds and
>>> swimming pools.
>>>
>>> Taking pictures of people is not a problem, it's what you do with them
>>> afterwards that is important. If you use the image yourself and map
>>> the things you see on them from your PC, it doesn't matter that there
>>> are people.
>>> If you post the image on a public website (as you do via
>>> StreetComplete), you have to make sure that there are no people or
>>> that their faces are blurred (e.g. uploading to Mapillary is OK I
>>> think).
>>>
>>> Of course, you cannot enter private grounds.
>>>
>>> On Thu, May 14, 2020 at 3:49 PM wbrt  wrote:
>>> >
>>> > Hello,
>>> >
>>> > a question about privacy of people in general (not the mapper) (in
>>> Belgium)
>>> >
>>> > when contributing using for example streetcomplete:
>>> https://github.com/westnordost/StreetComplete
>>> > answering the questions, i suppose this is ok juridical?
>>> >
>>> > when taking pictures to make it clear for the mappers,
>>> > i guess this also ok, as long as people are not recognizable in it?
>>> >
>>> > or am i wrong?
>>> > and can you get in trouble for contributing to openstreetmap?
>>> >
>>> > The info i found:
>>> >
>>> https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information
>>> >
>>> > kr
>>> > ___
>>> > Talk-be mailing list
>>> > Talk-be@openstreetmap.org
>>> > https://lists.openstreetmap.org/listinfo/talk-be
>>>
>>> ___
>>> Talk-be mailing list
>>> Talk-be@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] privacy ed

[Marc Gemis]

Hello,

I see no difference between contributing to OpenStreetMap via JOSM and
iD or StreetComplete.
Mapping a house, street, waste bin, etc. will not break any privacy.
We do not map the names of the inhabitants of a house. Mapping items
from someone's garden based on aerial imagery might be on the
borderline of what is allowed. However, I do map sheds, ponds and
swimming pools.

Taking pictures of people is not a problem, it's what you do with them
afterwards that is important. If you use the image yourself and map
the things you see on them from your PC, it doesn't matter that there
are people.
If you post the image on a public website (as you do via
StreetComplete), you have to make sure that there are no people or
that their faces are blurred (e.g. uploading to Mapillary is OK I
think).

Of course, you cannot enter private grounds.

On Thu, May 14, 2020 at 3:49 PM wbrt  wrote:
>
> Hello,
>
> a question about privacy of people in general (not the mapper) (in Belgium)
>
> when contributing using for example streetcomplete: 
> https://github.com/westnordost/StreetComplete
> answering the questions, i suppose this is ok juridical?
>
> when taking pictures to make it clear for the mappers,
> i guess this also ok, as long as people are not recognizable in it?
>
> or am i wrong?
> and can you get in trouble for contributing to openstreetmap?
>
> The info i found:
> https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information
>
> kr
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Patlatch (was Weggetje verdwenen, hoe terug ?)

[Marc Gemis]

Karel,

Ik dacht dat de ontwikkelaar van Potlatch bezig was met een
stand-alone versie. dwz dat je het niet meer in de browser kan
gebruiken, maar dat je nog wel met je vertrouwde editor verder kan.

mvg

m.

On Wed, May 13, 2020 at 10:57 AM Karel Adams  wrote:
>
> :) ikke, want Potlatch is het enige dat ik ken en voor mijn beperkte gebruik 
> voldoet dat prima; veel beter dan ID in alle geval.
>
> Maar het ziet ernaar uit dat Flash ten dode is opgeschreven dus ik zal wel 
> moeten overstappen :(
>
> KA
>
> On 2020-05-13 08:22, wannes wrote:
>
> Jaahaa, dat is met Flash, wie heeft dat nu nog ? :-)
>
> On Tue, May 12, 2020 at 3:03 PM Jo  wrote:
>>
>> Er is nog een 'truuk' om verwijderde ways terug te halen. (werkt enkel voor 
>> ways).
>>
>> Start editeersessie met Potlatch2.
>>
>> Je wilt eigenlijk de vorige versie van Potlatch gebruiken, haal daarom de 2 
>> weg uit de url in de adresbalk...
>>
>> De originele versie van Potlatch maakt gebruik van een niet gedocumenteerde 
>> 'feature' in de API.
>>
>> Er is een knop om deleted ways te zien.
>>
>> Jo
>>
>> On Tue, May 12, 2020 at 1:07 PM Tim Couwelier  
>> wrote:
>>>
>>> Bijlage bleeft hangen wegens groter dan 80kb, maar hierbij even ter 
>>> illustratie hoe je ze kan traceren met de 'skyview' laag.  Is een soort 
>>> hoogtemodelweergave op grondniveau, de bomen zie je dus niet.. en het pad 
>>> wordt zichtbaar.
>>>
>>> https://framapic.org/r01ExtbzPorU/Z1Zri8oU24QM.jpg
>>>
>>> (ik had al even afzonderlijk gemaild naar de betrokken persoon, maar 
>>> mogelijks zijn er nog mensen waarvoor dit een meerwaarde kan betekenen.)
>>>
>>>
>>> Op di 12 mei 2020 om 10:57 schreef Wannes Soenen :

 Ok, dan lijkt me het het “handigste” dat ik een GPX neem en het pad terug 
 teken (want het zit onder de bomen)
 Die relaties, en GR enz toevoegen/verleggen, zal ik eerst eens moeten 
 bestuderen, want dat heb ik nog nooit gedaan.

 Op 12 mei 2020, om 10:53 heeft Sander Deryckere  het 
 volgende geschreven:

 Hallo,

 Het hangt er van af hoe lang de wijziging geleden is.
 Als het vrij recent is (enkele dagen), kan je de geschiedenis van een 
 gebied opvragen (de geschiedenis knop op de hoofdpagina).
 Maar deze wijziging lijkt langer geleden te zijn, dus valt dit moeilijk te 
 bespeuren.

 Wat je wel kan is bekijken welke objecten waarschijnlijk ook gewijzigd 
 zijn bij die aanpassing (zoals het fietspad dat nu gebruikt wordt).

 

 Als je dat fietspad selecteert, en de geschiedenis opvraagt, dan kom je 
 hier terecht: https://www.openstreetmap.org/way/24520913/history

 Er is dus in de laatste maanden tamelijk wat aangepast aan het pad.  In 
 het bijzonder zie ik een wijziging van 4 maand geleden met het commentaar 
 "cycleroute 03-04 update: broken (again), now due to missing segments". 
 Wat er op wijst dat iemand er voor die regio heeft aangepast, zonder 
 rekening te houden met de relaties.

 Het is dus waarschijnlijk niet 1 iemand die de relatie verlegd heeft, maar 
 iemand heeft dat pad verwijderd, en iemand anders heeft de relatie opnieuw 
 verbonden met de bestaande paden...

 Mvg,
 Sander

 Op di 12 mei 2020 om 10:18 schreef Wannes Soenen :
>
> Hoi,
>
> Ik zie dat er zeer lokaal, een wegje verdwenen is op de kaart.
> Ik kan dat er zelf terug op gaan zetten, maar dan is de kans groot dat 
> diegene die de edit gedaan heeft het weer wist.
>
> Hoe kan ik 1) zien wie de edit deed, of er een comment bij was? 2) 
> rollback doen
>
> Het betreft een pad net ten zuiden van het Ringfietspad op 
> https://www.openstreetmap.org/edit#map=18/51.20462/4.44275
> De plaatselijke merkkringen van het GR-pad (en van op de GR site) loopt 
> wel degelijk over dat pad, niet over het fietspad.
> Dus, de huidige gemaakte situatie is fout, want 1) pad is niet meer 
> gemapt 2) GR loopt over het fietspad.
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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


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

Re: [OSM-talk-be] Telenav Mapping Project

[Marc Gemis]

Hallo Adrian,

thanks for reaching out before starting the project.

Just like the others here, I wonder how bad the situation is in
Brussels in your eyes. Do you have an overview of the wrong/missing
data that you will try to fix? Do you have a list of sources that you
will use to correct those problems? This information is missing in the
TelenavMapping page you are linking to.
Without this information, it's hard to tell whether your remote work
will improve the situation or undo the hard work of the local mapping
community.

As for Flandres, we had a "street complete' project a few years ago
that added all missing roads. Furthermore, before I had spent 2 years
or so on adding all the turn:lanes on motorways, trunk and primary
road, mainly in Flandres but also in Brussels and Wallonia. It might
be worth to do an update on that. Of course, in the meantime, others
have joined that project and have updated the data all over the
country.


regards

m.

On Wed, Apr 22, 2020 at 1:09 PM Adrian Budugan
 wrote:
>
> Hi all,
>
> I am Adrian and I am part of the Mapping Team at Telenav. Our team started an 
> editing project in Belgium to make OpenStreetMap more navigable and accurate 
> in guidance.
>
> We will start editing in Brussels at the end of April, next week. There are 
> more details here - 
> https://github.com/TelenavMapping/EU_mapping_projects/issues/4.
>
> We will focus on one ways, turn restrictions, road geometry and quality 
> assurance.
>
> We we'd love to hear your advice on any local mapping guidelines, besides the 
> general OSM mapping ones (http://wiki.openstreetmap.org/wiki/Main_Page, 
> http://wiki.openstreetmap.org/wiki/Map_Features).
>
> Also, we appreciate any hints regarding available local or government data 
> that we might be able to us or anything else that might come in handy.
>
> If there are any other OSM communication channels for Belgium, please let us 
> know.
>
> If you have any questions or comments, please let me/us know.
>
> We are looking forward to hearing from you.
>
>
>
> Thank you!
>
>
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Bunkers

[Marc Gemis]

are you sure it's not

building=bunker
abandoned:military=bunker

?

my reasoning is:  it's still a building, but no longer a military installation.

m.

On Tue, Mar 17, 2020 at 5:16 PM Lionel Giard  wrote:
>
> For abandonned (historic) military bunker, the correct mapping is :
> - abandonned:building=bunker
> - military=bunker
> - bunker_type=* (most of them are pillbox for those defensive belt around our 
> big cities)
> - historic=yes
> ...
>
> So that you get all the information that it is no longer in use ! ^_^
> Look on the wiki for more detailed tagging:  
> https://wiki.openstreetmap.org/wiki/Tag:military%3Dbunker
>
> Kind Regards,
> Lionel
>
> Le mar. 17 mars 2020 à 16:51, Marc M.  a écrit :
>>
>> Hello,
>>
>> Le 17.03.20 à 16:26, rodeo .be a écrit :
>> > I assume they were not visible because the tags were deprecated
>>
>> military=bunker isn't deprecated, it's the correct tag for a bunker
>> still in military use.
>>
>> I found at least one currently visible mapped with a node
>> https://www.openstreetmap.org/node/29049422
>> another mapped with an area https://www.openstreetmap.org/way/25586752
>>
>> Regards,
>> Marc
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] RFC: explicit tagging of 'Jaagpaden'

[Marc Gemis]

As we map what is on the ground, we do not have to care about that,  I
would assume. Let someone else fight with the people that place the signs.

m

Op di 3 mrt. 2020 20:10 schreef Steven Clays :

> To make it more complex, not every signposted towpath in Flanders is
> legally a towpath. Check
> http://www.start2boat.be/vaaropleiding/downloads/reglementen/Bijzondere%20reglementen.pdf
>
> Op di 3 mrt. 2020 om 19:38 schreef Stijn Rombauts via Talk-be <
> talk-be@openstreetmap.org>:
>
>> Hi,
>>
>> 'Jaagpaden' are not always paved roads. Often compacted, gravel, earthen,
>> grassy, ... roads/tracks and then highway=track seems a better choice.
>> Sometimes the only thing that's left is just a path. Then the tag
>> service=towpath is rather odd. I use description=jaagpad.
>> And what about similar roads which usually have the same access
>> restrictions but are called 'haven' or 'havengebied' instead of 'jaagpad'?
>>
>> Regards,
>>
>> StijnRR
>>
>>
>> Op dinsdag 3 maart 2020 16:28:46 CET schreef Pieter Vander Vennet <
>> pieterv...@posteo.net>:
>>
>>
>> Hey Marc,
>>
>> Thanks for your response.
>>
>> IMHO all towpaths are indeed peculiar service roads, thus
>> 'highway=service' + 'service=towpath'. The wiki even mentions explicitly
>> that it should be a service road.
>>
>> The examples you sent are excellent examples where the legal signposting
>> didn't catch up with the historic usage. These clearly used to be
>> towpath but they didn't gain the legal recognition of a 'jaagpad'.
>> Personally, I would tag those with 'service=towpath' (reflecting the
>> historic usage) but not with 'towpath=yes', but this is very subject to
>> change. We might even consider `towpath=no` (with a note clarifying this
>> is legally _not_ a 'jaagpad') or `legal:towpath=no` or something similar.
>>
>> Another thought: if we are about using 'towpath=yes' to reflect the
>> legal status, I'm doubting that there is no better tag scheme for this.
>>
>>
>> Kind regards, Pieter
>>
>>
>> On 03.03.20 16:12, Marc Gemis wrote:
>> > I'm fine with explicitly mapping them.
>> > Isn't service=towpath strange on a way that is not tagged as
>> > highway=service? (but you know that I think they should have been
>> > mapped as highway=service in the first place, but this is not the
>> > case)
>> >
>> > So it's meant for all those that are explicitly signed as "Jaagpad"
>> > and not for any others? So this
>> > https://www.mapillary.com/map/im/3T0U_uBJxNXHfrgwdztQDQ is not a
>> > Jaagpad? (a bit further
>> >
>> https://www.mapillary.com/app/?lat=51.05439739997222&lng=4.4334043&z=17&focus=photo&pKey=cmVJ5z_VXnZqwsdrEK0aHw
>> > , but that still does not make it a Jaadpad?)
>> >
>> > m.
>> >
>> > On Tue, Mar 3, 2020 at 2:14 PM Pieter Vander Vennet
>> >  wrote:
>> >> Hello everyone,
>> >>
>> >> Even though the legal restrictions of 'Jaagpaden' (towpaths in proper
>> English) is already described in detail on the wiki, it would still be
>> useful to reflect the special status explicitly, in our case to give a
>> comfort bonus in cycling route planning but also for historical purposes.
>> >>
>> >> For context, a 'jaagpad', 'trekpad' or towing path is a path that used
>> to be used to (literally) tow boats through the canals, either with
>> manpower or horsepower and a rope attached to the boat - hence there are
>> never trees between a towpath.
>> >>
>> >> With the rise of cheap and powerful combustion engines, this practice
>> became disused and towpaths became service roads and cycleways.
>> >>
>> >> As stated, these often are excellent and heavily preferred by
>> cyclists. Normally, they are wide, asphalted, there are very few cars and
>> especially: there is the very nice scenery of the canal.
>> >>
>> >> Therefore, I would propose to introduce tagging in Belgium to tag
>> towpaths.
>> >>
>> >>
>> >> There are two ways to achieve this:
>> >>
>> >> - A towpath is typically a specific type of service road, so we can
>> add `service=towpath`
>> >>
>> >> - In the UK, the towpaths are tagged with `towpath=yes`
>> >>
>> >>

Re: [OSM-talk-be] RFC: explicit tagging of 'Jaagpaden'

[Marc Gemis]

Hgw=service can be unpacked and tracks can be paved.  The difference is the
function,  not the surface

m

Op di 3 mrt. 2020 19:38 schreef Stijn Rombauts via Talk-be <
talk-be@openstreetmap.org>:

> Hi,
>
> 'Jaagpaden' are not always paved roads. Often compacted, gravel, earthen,
> grassy, ... roads/tracks and then highway=track seems a better choice.
> Sometimes the only thing that's left is just a path. Then the tag
> service=towpath is rather odd. I use description=jaagpad.
> And what about similar roads which usually have the same access
> restrictions but are called 'haven' or 'havengebied' instead of 'jaagpad'?
>
> Regards,
>
> StijnRR
>
>
> Op dinsdag 3 maart 2020 16:28:46 CET schreef Pieter Vander Vennet <
> pieterv...@posteo.net>:
>
>
> Hey Marc,
>
> Thanks for your response.
>
> IMHO all towpaths are indeed peculiar service roads, thus
> 'highway=service' + 'service=towpath'. The wiki even mentions explicitly
> that it should be a service road.
>
> The examples you sent are excellent examples where the legal signposting
> didn't catch up with the historic usage. These clearly used to be
> towpath but they didn't gain the legal recognition of a 'jaagpad'.
> Personally, I would tag those with 'service=towpath' (reflecting the
> historic usage) but not with 'towpath=yes', but this is very subject to
> change. We might even consider `towpath=no` (with a note clarifying this
> is legally _not_ a 'jaagpad') or `legal:towpath=no` or something similar.
>
> Another thought: if we are about using 'towpath=yes' to reflect the
> legal status, I'm doubting that there is no better tag scheme for this.
>
>
> Kind regards, Pieter
>
>
> On 03.03.20 16:12, Marc Gemis wrote:
> > I'm fine with explicitly mapping them.
> > Isn't service=towpath strange on a way that is not tagged as
> > highway=service? (but you know that I think they should have been
> > mapped as highway=service in the first place, but this is not the
> > case)
> >
> > So it's meant for all those that are explicitly signed as "Jaagpad"
> > and not for any others? So this
> > https://www.mapillary.com/map/im/3T0U_uBJxNXHfrgwdztQDQ is not a
> > Jaagpad? (a bit further
> >
> https://www.mapillary.com/app/?lat=51.05439739997222&lng=4.4334043&z=17&focus=photo&pKey=cmVJ5z_VXnZqwsdrEK0aHw
> > , but that still does not make it a Jaadpad?)
> >
> > m.
> >
> > On Tue, Mar 3, 2020 at 2:14 PM Pieter Vander Vennet
> >  wrote:
> >> Hello everyone,
> >>
> >> Even though the legal restrictions of 'Jaagpaden' (towpaths in proper
> English) is already described in detail on the wiki, it would still be
> useful to reflect the special status explicitly, in our case to give a
> comfort bonus in cycling route planning but also for historical purposes.
> >>
> >> For context, a 'jaagpad', 'trekpad' or towing path is a path that used
> to be used to (literally) tow boats through the canals, either with
> manpower or horsepower and a rope attached to the boat - hence there are
> never trees between a towpath.
> >>
> >> With the rise of cheap and powerful combustion engines, this practice
> became disused and towpaths became service roads and cycleways.
> >>
> >> As stated, these often are excellent and heavily preferred by cyclists.
> Normally, they are wide, asphalted, there are very few cars and especially:
> there is the very nice scenery of the canal.
> >>
> >> Therefore, I would propose to introduce tagging in Belgium to tag
> towpaths.
> >>
> >>
> >> There are two ways to achieve this:
> >>
> >> - A towpath is typically a specific type of service road, so we can add
> `service=towpath`
> >>
> >> - In the UK, the towpaths are tagged with `towpath=yes`
> >>
> >> Note that towpaths in Flanders are mostly signposted with an official
> sign, even though that this is a bit of a legal remnant of a previous era.
> However, it makes it very explicit and thus unambiguous to map.
> >>
> >> But now, for the serious questions:
> >>
> >> - what are your thoughts of mapping them somehow? IMHO it is an added
> value and I'm quite in favour of them.
> >>
> >> - What is the best way of mapping them? I'm a bit on the edge of the
> options above: `service=towpath` is IMHO semantically the most correct
> form, as it indicates that it is a service road o

Re: [OSM-talk-be] #equalstreetnames

[Marc Gemis]

Hello Seppe

thanks a lot for sharing this information.
I do like the project (despite my comments on obtaining the data
before the start) because:

- it uses my 2 favourite crowd-sourced open data projects
- it really requires both projects to create the map
- Open Street Maps (sic) is not only used as background nor for navigation
- it brought together 60 people. I do hope they will somehow continue
to contribute to OSM and/or Wikidata
- It gave OSM and Wikidata some publicity

As for the criticism on participating in an event that tries to gather
data on gender inequality in street names.
I do not see any political statement in that. After all, OSM and
Wikidata are very natural sources for such events, as, you might have
guessed it, are open data. If one makes a political statement with
that,  mapping bicycle parking could be seen as supporting anti-car
policies as well.

I assume mappers are often activists or at least passionate for
certain features, be it slow roads, airfields, AEDs, historical
buildings, power infrastructure etc. We are often open data and open
source activists as well.
Recently, on the tagging mailing list, you see requests for tags to
map free drinking water, free refills, object sharing, food sharing,
etc. All those are somehow driven by activism. Is that wrong? Not in
my opinion, it enriches the OSM project. If we would only try to mimic
Google Maps by focussing on navigation and shops (for advertising), we
could as well stop now.

So thank you for setting up the project and let's hope it will hellp
OSM grow further in the future.

regards

m.

On Tue, Mar 3, 2020 at 12:39 PM Santens Seppe  wrote:
>
> Hi all,
>
>
>
> Today, #equalstreetnames was launched, something Open Knowledge / OSM Belgium 
> (among others) can be very proud of if you ask me. The project combines OSM 
> and Wikidata (+ extra data crowdsourced during a workshop) to make this map: 
> https://equalstreetnames.brussels/ (stunning isn’t it?). More info on why an 
> how can be found in this blogpost: 
> https://be.okfn.org/2020/03/03/equalstreetnames-brussels-launch-of-open-data-visualisation/
>
>
>
> The project already got some nice media coverage, e.g. 
> https://www.bruzz.be/samenleving/nauwelijks-brusselse-straten-naar-vrouwen-vernoemd-trage-inhaalbeweging-2020-03-03
>  and 
> https://www.rtbf.be/info/dossier/les-grenades/detail_combattre-le-sexisme-en-rebaptisant-les-rues-de-bruxelles?id=10446433
>
>
>
> Of course, you can help spread the word, e.g. by sharing
>
> https://www.facebook.com/OpenKnowledgeBE/photos/a.376589912722798/1030439804004469/?type=3&theater
>
> https://twitter.com/OpenKnowledgeBE/status/1234754767756386304
>
> https://www.linkedin.com/posts/open-knowledge-belgium_opendata-activity-6640521647684100096-GvRU
>
>
>
>
>
> Best regards,
>
>
>
> Seppe
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] RFC: explicit tagging of 'Jaagpaden'

[Marc Gemis]

I'm fine with explicitly mapping them.
Isn't service=towpath strange on a way that is not tagged as
highway=service? (but you know that I think they should have been
mapped as highway=service in the first place, but this is not the
case)

So it's meant for all those that are explicitly signed as "Jaagpad"
and not for any others? So this
https://www.mapillary.com/map/im/3T0U_uBJxNXHfrgwdztQDQ is not a
Jaagpad? (a bit further
https://www.mapillary.com/app/?lat=51.05439739997222&lng=4.4334043&z=17&focus=photo&pKey=cmVJ5z_VXnZqwsdrEK0aHw
, but that still does not make it a Jaadpad?)

m.

On Tue, Mar 3, 2020 at 2:14 PM Pieter Vander Vennet
 wrote:
>
> Hello everyone,
>
> Even though the legal restrictions of 'Jaagpaden' (towpaths in proper 
> English) is already described in detail on the wiki, it would still be useful 
> to reflect the special status explicitly, in our case to give a comfort bonus 
> in cycling route planning but also for historical purposes.
>
> For context, a 'jaagpad', 'trekpad' or towing path is a path that used to be 
> used to (literally) tow boats through the canals, either with manpower or 
> horsepower and a rope attached to the boat - hence there are never trees 
> between a towpath.
>
> With the rise of cheap and powerful combustion engines, this practice became 
> disused and towpaths became service roads and cycleways.
>
> As stated, these often are excellent and heavily preferred by cyclists. 
> Normally, they are wide, asphalted, there are very few cars and especially: 
> there is the very nice scenery of the canal.
>
> Therefore, I would propose to introduce tagging in Belgium to tag towpaths.
>
>
> There are two ways to achieve this:
>
> - A towpath is typically a specific type of service road, so we can add 
> `service=towpath`
>
> - In the UK, the towpaths are tagged with `towpath=yes`
>
> Note that towpaths in Flanders are mostly signposted with an official sign, 
> even though that this is a bit of a legal remnant of a previous era. However, 
> it makes it very explicit and thus unambiguous to map.
>
> But now, for the serious questions:
>
> - what are your thoughts of mapping them somehow? IMHO it is an added value 
> and I'm quite in favour of them.
>
> - What is the best way of mapping them? I'm a bit on the edge of the options 
> above: `service=towpath` is IMHO semantically the most correct form, as it 
> indicates that it is a service road originally built for towing. 
> `towpath=yes` reeks more of the legal status (i.e. having a formal road sign 
> indicating 'jaagpad'). The latter has the advantage of already being in use 
> in the UK with over 3500 instances according to taginfo. service=towpath is 
> not in use at the moment.
>
>
> PS: fun etymological fact: the English verb 'to tow' is derived from the 
> Dutch word for rope: 'touw'
>
> --
> Met vriendelijke groeten,
> Pieter Vander Vennet
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data

[Marc Gemis]

> About the geocoding. If I look at the street in my JOSM, then create a node 
> somewhere in the center of it and then add the coordinates of that node to 
> Wikidata, did I violate any rights? If it does, we could use Urbis data to 
> source coordinates for the whereabouts of the street. I'm not using any nodes 
> of the street itself. I do try to link back to openstreetmap (one of the ways 
> or associatedStreet relation) in the reference url field.
>

IMHO, that is a derivative database. You look at OSM data, apply some
algorithm and create new data.
AFAIK, the project that Seppe, Joost and Jonathan have will not add
such data, but if you want to do it, you might contact the LWG to be
sure it's OK. I doubt it is.

regards

m.

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

Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data

[Marc Gemis]

As I wrote on Riot, I do hope this event will not copy geocoded data
from OSM into Wikidata, I think this violates
https://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline
Please let me know if I'm wrong.

regards

m.

On Tue, Feb 4, 2020 at 12:08 PM Jo  wrote:
>
> Hi,
>
> I did this for one street in Evere: 
> https://www.openstreetmap.org/way/523050554/history
>
> Took me more than half an hour for a single street (no automation). I created 
> a wikidata entry both for the person and for the street itself. Things are 
> complicated by the bilingual nature of the city and because this street also 
> had an old name.
>
> Is that what we will be doing? Or did I somehow misunderstand?
>
> Polyglot
>
> On Mon, Feb 3, 2020 at 4:34 PM Santens Seppe  wrote:
>>
>> Hi community,
>>
>>
>>
>> Open Knowledge Belgium, OpenStreetMap Belgium and Wikimedia Belgium want to 
>> map all the streetnames by gender in Brussels, as a first step to change the 
>> imbalance in reality. We need your help on 17/02 to get the OSM data linked 
>> to wikidata.
>>
>> Register here to join the mapping effort: 
>> https://eventbrite.co.uk/e/towards-equal-street-names-with-open-data-registration-92536026747.
>>  And let us know if you can help with the framework.
>>
>>
>>
>>
>>
>> more info: 
>> https://be.okfn.org/2020/02/03/towards-equal-street-names-with-open-data/
>>
>>
>>
>> Please spread the word!
>>
>> -Twitter: https://twitter.com/OpenKnowledgeBE/status/1224291464496193538
>> -Facebook: https://www.facebook.com/events/2852981998057886/
>> -Eventbrite: http://equalstreetnamesbrussels.eventbrite.co.uk/
>>
>>
>>
>>
>>
>> Seppe
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] 500 defibrillators gemapillariseerd

[Marc Gemis]

> We zijn echter maar met 2 mappers die de AEDs serieus nemen.  Er zijn zelfs 
> mappers die om elitaire redenen geen foto willen nemen en liever mensen laten 
> sterven.

Kunnen we dit provocerend gedrag aub achterwege laten ?

prettige feestdagen iedereen

m.

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

Re: [OSM-talk-be] Tagging proposal for cycling highways (Fietssnelwegen)

[Marc Gemis]

I would assume that something like cycle.travel will compute a
bicycle-friendly route for the missing parts if all streets are mapped
properly with max speed, cycleways, surfaces, etc. There is indeed no
need/justification to map personal preferences/suggestions.

If the routes calculated by dedicate cycle routers are not taking the
best route, why not discuss this with the developers and see whether
they can improve their algorithms or perhaps they can suggest you to
add additional info that has an impact on routes. I did that in the
past for my home-to-work itinerary.

regards

m.

On Tue, Dec 24, 2019 at 12:50 AM Jo  wrote:
>
> Go ahead, they are not important to me. I was trying to create itineraries 
> that get you from one place to another today, instead of in 5 or 10 years.
>
> I like to see bicycle routes that are continuous. That is usually not 
> possible today on any of the fietsnelwegen.
>
> Jo
>
> On Mon, Dec 23, 2019, 23:40 EeBie  wrote:
>>
>> I agree with the remarks of Stijn. Only the parts of the "Fietssnelwegen" 
>> that are realized and “Befietsbaar” on the website of Fietssnelwegen and/or 
>> marked in the field as such, should be on OSM as cycle route.
>> During the past 2 years I suffered several times from the unreliable 
>> information on OSM as a user of OSM based bike route planners. Planned cycle 
>> highways were put on the map as realized and existing. A bike routeplanner 
>> makes a route with preference to cycle routes that are on OSM. I supposed to 
>> follow a cycle highway but landed on a single track path of 30 cm wide with 
>> surface of soft sand that I had to walk. On another spot I was following a 
>> paved footway and had to squeeze my brakes at once because the paved footway 
>> went over in a stairs downwards where a bridge will be build in the future. 
>> Luckily it was in daylight and feasible; users of cycle highways are 
>> supposed to take these routes before and after work when it is dark.The 
>> proposed routes on OSM are dangerous.
>>
>> I have given that cycle highway relation the state proposed=yes that makes 
>> that they are not taken in account on bike routeplanners and on 
>> https://cycling.waymarkedtrails.org (those proposed relations are visible on 
>> the Bike Map layer on OSM cycle map layer ). There was a fixme or incomplete 
>> remark on those relations of planned cycle highways but those doesn’t make 
>> that they are neglected by routeplanners.
>>
>> I have put the proposed state on other cycle highways that were mapped as 
>> going through fences over private industrial premises and others where 
>> biking was not permitted or where even was no path at all.
>>
>> I have deleted parts of cycle highways in the route relation where bike 
>> riding wasn’t possible as for example on railway bridge where the bridge 
>> wasn’t ready a few months back (maybe it is meanwhile, but I wasn’t there 
>> recently).
>>
>> A few years back I have mapped parts of cycle highways that where ready and 
>> marked and put on the website as “Befietsbaar” in a route relation but I had 
>> to notice that parts that weren’t ready were added to those relations.
>>
>> I also don’t like the “alternative cycle highways” because they only exist 
>> in the head of one person and their quality is (in a lot of cases) very poor 
>> and dangerous. Example: https://www.openstreetmap.org/way/17298358 If you 
>> take this path riding on modal electric bike style downwards from the 
>> embankment of the canal over a small unpaved path to a narrow bridge over a 
>> ditch, you are death. And that should be highway for bikes.
>>
>> I propose to delete all what is “alternatief Fietssnelweg” because they are 
>> non existing and they make OSM unreliable because those routes are put as 
>> preferred by routeplanners.
>>
>> For the F Fietswegen I propose to delete the parts that are not ready from 
>> the route relations and leave the parts that are ready and “Befietsbaar” as 
>> on the on Fietssnelwegen website (putting the “proposed” status to a 
>> complete F relation isn’t a solution any more because parts of them are 
>> released as “Befietsbaar”).
>>
>> Regards,
>>
>> Eebie
>>
>>
>>
>>
>> Op 23/12/19 om 21:10 schreef Stijn Rombauts via Talk-be:
>>
>> Hi,
>>
>> I don't understand why nobody else objects to the 'alternatives'. They're 
>> just somebody's personal inventions, but they do not exist. If we allow Jo's 
>> alternatives, then we have to allow anybody's alternatives, suggestions , 
>> etc. for cycle highways or any other kind of hiking, cycle, ... routes. E.g. 
>> the cycle highway between Diest and Hasselt has been deleted: can I add to 
>> OSM a good alternative that I use daily? I hope the aswer is no. I don't 
>> mind that somebody suggests on some website alternatives for the cycle 
>> highways which do not yet exist. It's even a very good idea, but please keep 
>> them out of the OSM database.
>> In my opinion, only those parts which are already waymarked should be in 

Re: [OSM-talk-be] Tagging proposal for cycling highways (Fietssnelwegen)

[Marc Gemis]

> Tagging scheme
>
> I'd actually go for `cycle_network=BE:cycle_highway`, as cycle_network 
> normally has a country prefix. Because most (all?) of them are already 
> tagged, we could simply update the tagging all at once.  I'll do that next 
> week, unless a better proposal or good reason not to is raised.

to be honest I find "network" strange in the context of a single
cycle_highway. All cycle_highways together form a network, but a
single one not.
We do not map the E 19 motorway as car_network:BE:motorway, but we do
have a relation for all parts of the E 19 in a route-relation (I
think, OSM website was soo slow yesterday when I tried to access the
page on E-motorways).

Is this cycle_network value OK with the inventors of that tag ? Wasn't
it invented recently to distinguish cycle networks from local cycle
routes ?

In conclusion: I would prefer another way to tag cycle highways

regards

m

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

Re: [OSM-talk-be] Encrypted Message

[Marc Gemis]

Wijze woorden, Pieter !


m.

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

Re: [OSM-talk-be] Overdreven gedetailleerde mapping ?

[Marc Gemis]

>
> Een aansluitend vraagje: heeft het nog zin om iemand te wijzen op fouten die 
> 2, 3, 4, ... jaren geleden zijn gemaakt? Wat doen jullie?
>

normaal gezien probeer ik het probleem op te lossen zonder de ander te
contacteren. Ook als het niet zo lang geleden is.
ik contacteer alleen
- als het veel werk is of te moeilijk
- een systematische fout
+ ik zin heb om de moeite te nemen.

dus heel zelden.

ook al omdat "wie zonder zonde is werpe de eerste steen". ik heb
volgens Osmose ook veel fouten/waarschuwingen, maar ik ben het ook
niet altijd eens met hun rapportering. (e.g.. lanes-counting, walking
network relations)

Het is vooral belangrijk om iemand te contacteren, als je denkt dat
die persoon kan bijleren, of om hen een halt toe te roepen. Anders
heeft het weinig zin vind ik.

mvg

m

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

Re: [OSM-talk-be] Overdreven gedetailleerde mapping ? Exaggerated detailed mapping?

[Marc Gemis]

> And to be honest: I don't think OSM will really surpass commercial maps for 
> car navigation, because up to date traffic information is part of that.
> I don't see how volunteers can arrange that quickly.

In some countries (including Belgium) traffic information from the
government is open data. Some OSM based apps, such as Magic Earth or
MapsFactor Navigator use this information. I have driven to Austria
this year with Magic Earth and the GPS in my car. There was not a lot
of difference in accuracy regarding traffic information.
The traffic slow down on the R0 I went through today was also
announced via Magic Earth.

Waze is also an app that uses volunteers to gather traffic
information. The beta version of Magic Earth that I'm testing now
allows people to send information about road works, traffic jams etc.
to the central servers. Just like Waze.

Some car manufacturers (e.g. BMW) use statistics from the cars of that
brand to gather up-to-date traffic information. Magic Earth does this
as well from their installed base.

So it depends more on the features of your OSM based navigation app
than anything else.
If you are not satisfied with OsmAnd for car navigation, I really
recommend you to try out Magic Earth.

regards

m.

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

Re: [OSM-talk-be] Mapillary tip bij regen

[Marc Gemis]

On Thu, Nov 7, 2019 at 9:58 AM Jo  wrote:
>
> Why would you press against the camera?

To clean the lens. Even gently wiping over it would work against the
motors of the gimbal I think. It seems that the one I have can cope
with the duration of my walks.

To be honest, I think that the pictures I made are good enough to see
plenty of things that can be mapped. The parking places discussed
earlier, a bread vending machine etc, are still visible and can be
mapped. When I cannot read a label anymore, yes, then the picture is
worthless.
The pictures might be washed out here and there, but hey, I can live
with that. I can start mapping now and do not have to wait to get back
there when it's dry. For me, Mapillary is a source to map, not a
beauty contest for taking nice pictures. And furthermore, their object
recognition algorithms should be able to cope with raindrops,
otherwise, they will be useless in many real-world situations.

So I will keep taking pictures with light rain.

m.

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

Re: [OSM-talk-be] Mapillary tip bij regen

[Marc Gemis]

Ik vrees een beetje voor mijn gimbal als ik dat doe.
Voorlopig zie ik het maar als een test voor de object herkenning van
Mapillary :-)

Iemand ervaring met gimbals als je telkens weer opnieuw tegen de camera duwt ?
(Anyone experience with gimbals when you keep pressing against the
camera over and over again
?)

m.

On Tue, Nov 5, 2019 at 1:10 PM Philippe Casteleyn
 wrote:
>
> https://www.mapillary.com/app/?focus=photo&pKey=tyzRIji1MXSDUcxAxoxFoQ&lat=51.04352509997222&lng=4.263778&z=17
>
> Wanneer het regent droog ik mijn cameralens bij elke straathoek.
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Road side parking ( Was Re: Overdreven gedetailleerde mapping ?)

[Marc Gemis]

so for https://www.mapillary.com/map/im/tyzRIji1MXSDUcxAxoxFoQ (the
spot from the previous mail)

parking:lane:both=marked
parking:lane:left:type=on_kerb  (*)
parking:lane:right:type=half_on_kerb (*)
parking:lane:right:capacity=2
parking:lane:left:capacity=2
parking:condition:both=free

(*) perhaps left and right has to be switched here.

Should I somehow tag the fact that only cars can park there (and no
long vans as in the picture, nor trucks) ?

On Tue, Nov 5, 2019 at 11:00 AM Lionel Giard  wrote:
>
> Yes technically this is how to map it (at least how it is documented), and 
> using the mandatory tag "parking:condition" in combination give indication 
> for people looking at roadside parking (one viewer show these : 
> https://zlant.github.io/parking-lanes/#15/50.9452/3.1233  with Roeselare as a 
> somewhat good example as it is well mapped). It is primarily for showing 
> parking conditon (is it allowed to park ? How much time ?...). But indeed, 
> the tagging scheme can be improved ! ^_^
>
> Maybe use a combination of the two : parking_space to show the individual 
> space (and so the capacity) and parking:lane=* + parking:condtion=* to show 
> the roadside parking and condition of parking. :-)
>
> Kind Regards,
>
> Le mar. 5 nov. 2019 à 10:06, Marc Gemis  a écrit :
>>
>> So for those 4 roadside parking spaces: https://osm.org/go/0EpBwBaxP?m=
>> I have to split the road a couple of times, add some 3 or 4 parking
>> lane tags to indicate it is somehow on both sides, parallel parking in
>> marked spots? And I wouldn't be able to add the capacity in the end.
>>
>> While adding 4 rectangles with tag amenity=parking_space express the same?
>>
>> For me, there is definitely improvement possible in the tagging schema
>> for such situations.
>>
>> m.
>>
>>
>> On Tue, Nov 5, 2019 at 9:26 AM Lionel Giard  wrote:
>> >
>> > @Marc These parking along street are indeed often not "amenity=parking" 
>> > but probably more related to parking:lane tag (tagged on the highway 
>> > itself). Technically it is suggested to only map these kind of roadside 
>> > parking with the parking:lane tag on the street.
>> > But yes, it could be mapped with amenity=parking_space (without 
>> > amenity=parking around it). and we could maybe use the 
>> > "type=site"+"site=parking" relation to group them (as it is suggested for 
>> > complex parking lot already) and allow people to understand that it is 
>> > linked to the road (including the street line in the relation) and that it 
>> > is roadside parking. But it is undocumented to use it that way. ^^
>> >
>> > Le mar. 5 nov. 2019 à 08:42, Marc Gemis  a écrit :
>> >>
>> >> Ik map soms ook parkeerplaatsen in een straat met enkel
>> >> amenity=parking_space, omdat er geen parking (in de betekenis van
>> >> parkeerterrein) is.
>> >> Ik vind niet dat elke groep van een paar parkeerplaatsen in een straat
>> >> parkings zijn. En het wordt gerenderd, dus kan je je afvragen of de
>> >> wiki niet moet aangepast worden voor zulke gevallen ?
>> >>
>> >> m.

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

[OSM-talk-be] Road side parking ( Was Re: Overdreven gedetailleerde mapping ?)

[Marc Gemis]

So for those 4 roadside parking spaces: https://osm.org/go/0EpBwBaxP?m=
I have to split the road a couple of times, add some 3 or 4 parking
lane tags to indicate it is somehow on both sides, parallel parking in
marked spots? And I wouldn't be able to add the capacity in the end.

While adding 4 rectangles with tag amenity=parking_space express the same?

For me, there is definitely improvement possible in the tagging schema
for such situations.

m.


On Tue, Nov 5, 2019 at 9:26 AM Lionel Giard  wrote:
>
> @Marc These parking along street are indeed often not "amenity=parking" but 
> probably more related to parking:lane tag (tagged on the highway itself). 
> Technically it is suggested to only map these kind of roadside parking with 
> the parking:lane tag on the street.
> But yes, it could be mapped with amenity=parking_space (without 
> amenity=parking around it). and we could maybe use the 
> "type=site"+"site=parking" relation to group them (as it is suggested for 
> complex parking lot already) and allow people to understand that it is linked 
> to the road (including the street line in the relation) and that it is 
> roadside parking. But it is undocumented to use it that way. ^^
>
> Le mar. 5 nov. 2019 à 08:42, Marc Gemis  a écrit :
>>
>> Ik map soms ook parkeerplaatsen in een straat met enkel
>> amenity=parking_space, omdat er geen parking (in de betekenis van
>> parkeerterrein) is.
>> Ik vind niet dat elke groep van een paar parkeerplaatsen in een straat
>> parkings zijn. En het wordt gerenderd, dus kan je je afvragen of de
>> wiki niet moet aangepast worden voor zulke gevallen ?
>>
>> m.

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

Re: [OSM-talk-be] Overdreven gedetailleerde mapping ?

[Marc Gemis]

Ik map soms ook parkeerplaatsen in een straat met enkel
amenity=parking_space, omdat er geen parking (in de betekenis van
parkeerterrein) is.
Ik vind niet dat elke groep van een paar parkeerplaatsen in een straat
parkings zijn. En het wordt gerenderd, dus kan je je afvragen of de
wiki niet moet aangepast worden voor zulke gevallen ?

m.

On Mon, Nov 4, 2019 at 4:33 PM Stijn Rombauts via Talk-be
 wrote:
>
> Even terug naar de aanpassingen van Jakka en ook wat aansluitend op 
> onderstaande opmerking van Marc. En ook omdat ik in alle stilte al wel wat 
> werk van Jakka heb verbeterd (en dan bedoel ik effectief: fouten corrigeren):
> - parkeerplaatsen: Jakka heeft daar de individuele parkeerplaatsen gemapt; op 
> zich OK. Maar waarom een aantal wel en de andere niet? En vergeet dan niet de 
> amenity=parking (toegevoegd door Anakil): m.a.w. zorg er op z'n minst voor 
> dan eerst de grote lijnen in orde zijn, voeg pas daarna de details toe (wiki: 
> Mapping parking spaces is an addition, not a replacement, to mapping a whole 
> parking lot with amenity=parking.) Jakka had trouwens een paar 
> parkeerplaatsen foutief gemapt met amenity= parking. Daarna heeft ene 
> philippec binnen de amenity=parking van Anakil nog eens 2 keer een amenity 
> =parking toegevoegd (zoals deze 
> https://www.openstreetmap.org/way/741861188)...? Waarom?
> - nog parkeerplaatsen: daar (https://www.openstreetmap.org/way/731154048) 3 
> brede parkeerplaatsen getekend terwijl het er 5 smalle zijn...
> - https://www.openstreetmap.org/way/118797990: lanes=2 --> lanes=1, maar 
> turn:lanes=none|merge_to_left vergeten te verwijderen en ook 
> cycleway:right=lane vergeten te verwijderen
> - het gebruik van traffic_calming=island (volgens wiki: A structure 
> separating at least two lanes of a highway from each other for a short 
> distance.). Dan lijkt dat daar (aan het stukje Zemstbaan dat aansluit op de 
> Brusselsesteenweg) heel veel verkeerd gebruikt. Alleen al omdat die 'dingen' 
> daar niks met traffic calming te maken hebben, volgens mij.
> - een aantal fietspaden zijn apart bijgetekend (OK), maar waarom niet het 
> stukje langs de Zemstbaan van Zemstsesteenweg naar Brusselsesteenweg? De 
> oneway-tag lijkt mij ook een aantal keer te ontbreken. En ook de 
> bicycle=use_sidepath op de highways is niet toegevoegd...
>
> Dat dingen in osm van jaren oud verbeterd, verfijnd of geüpdatet moeten 
> worden, is logisch. Maar dat recente veranderingen nog hopen extra werk 
> vragen omdat ze zeer onvolledig of ronduit fout zijn, vind ik behoorlijk 
> frustrerend. En met zo'n aanpassingen wordt de databank er ook echt niet 
> bruikbaarder op. Soit, 't is ook mijn eigen schuld omdat ik er anderen zelden 
> op aanspreek. En Jakka, jij bent zeker de ergste nog niet, verre van.
>
> StijnRR
>
>
> Op maandag 4 november 2019 13:08:24 CET schreef Marc Gemis 
> :
>
>
> > Wel pleit ik er voor een zeker 'gebiedje' dan wel op een gelijke maatstaf 
> > te behandelen. Als je het doet, zorg dan dat je consequent bent, voor de 
> > wijk of als het even kan je kleine gemeente.
>
> er is ook zoiets als "guerilla mapping"
> (http://sk53-osm.blogspot.com/2011/01/ive-been-guerilla-mapped.html)
>
>
> m.
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Overdreven gedetailleerde mapping ?

[Marc Gemis]

> Wel pleit ik er voor een zeker 'gebiedje' dan wel op een gelijke maatstaf te 
> behandelen. Als je het doet, zorg dan dat je consequent bent, voor de wijk of 
> als het even kan je kleine gemeente.

er is ook zoiets als "guerilla mapping"
(http://sk53-osm.blogspot.com/2011/01/ive-been-guerilla-mapped.html)

m.

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

Re: [OSM-talk-be] Overdreven gedetailleerde mapping ?

[Marc Gemis]

 men kan er zelfs
>> bijdragen zonder een account aan te maken. Er verschijnt daar dan ook
>> heel wat junk, en er is een gedefinieerde procedure om dat op te kuisen
>> ("Article for Deletion"). Aan een dergelijke aanpak ontbreekt het bij
>> OSM, en ik mis eraan. De huidige wollige aanpak kan nmbm niet blijven
>> duren. Al dient het gezegd dat Wikipedia een encyclopedie maakt, en dus
>> bewust en systematisch de lat hoog legt; en tegelijk veel zichtbaarder
>> is, en dus veel meer blootgesteld aan vandalisme, waardoor er veel meer
>> nood is aan procedures en strikte regels.
>>
>> Dank voor de openhartige en beleefde discussie!
>>
>> Karel
>>
>> On 11/2/19 9:45 PM, Marc Gemis wrote:
>> > Ik sluit me volledig aan bij Jakka. Ieder mapt wat hij/zij wil.
>> >
>> > Het aantal parkeerplaatsen kan interessante info zijn, net zoals de
>> > exacte ligging (misschien voor slechtzienden die over het terrein
>> > moeten navigeren). Kleine bloemperken e.d. geven aan hoe groen een
>> > stad is.
>> >
>> > Zo zijn er misschien ook mensen die zich afvragen wat het nut is van
>> > afzonderlijke fietspaden of landingsbanen op een vliegveld of om het
>> > even welk topic dat jij wel belangrijk vindt.
>> >
>> > Je hoort dit soort commentaren wel meer (en ik heb waarschijnlijk zelf
>> > ook al wel die fout gemaakt, maar ik probeer ze niet terug te maken)
>> > "ik vind dat X niet gemapped moet worden". OSM is een project met vele
>> > gezichten en veel verschillend gebruik. Daar moet je mee leren leven.
>> >
>> > Afhankelijk van wat Karel opkuisen noemt (verwijderen?), kan ik me
>> > voorstellen de DWG hem op de vingers tikt. Mappen op een plek die je
>> > niet kent brengt altijd gevaren met zich mee. Dit lijkt me een typisch
>> > verhaal van wie zijn * verbrand, moet op de blaren zitten. Het is een
>> > beetje raar dat hij eerst over opkuisen van bloemperken spreekt en dan
>> > over technisch verkeerd.
>> >
>> > mvg
>> > & happy mapping van om het even wat je belangrijk vindt, (bij voorkeur
>> > wel lokaal na survey ;-) )
>> >
>> > On Sat, Nov 2, 2019 at 4:55 PM Jakka  wrote:
>> >> Op 2/11/2019 om 14:37 schreef Denis Verheyden:
>> >>> Dag allen,
>> >>>
>> >>> Na een tijdje inactiviteit ben ik opnieuw wat verbeteringen op OSM aan
>> >>> het aanbrengen (kleine stukjes GRB-import, aanvullen of verbeteren
>> >>> huidige situaties).
>> >>> Echter kwam ik onlangs een geval tegen dat mijns inziens overdreven
>> >>> gedetailleerde mapping is:
>> >>>
>> >>> https://www.openstreetmap.org/#map=19/50.99435/4.47499
>> >>>
>> >>> <https://www.openstreetmap.org/#map=19/50.99435/4.47499>
>> >>>
>> >>> OpenStreetMap <https://www.openstreetmap.org/#map=19/50.99435/4.47499>
>> >>> OpenStreetMap is a map of the world, created by people like you and free
>> >>> to use under an open license. Hosting is supported by UCL, Bytemark
>> >>> Hosting, and other partners.. Learn More Start Mapping
>> >>> www.openstreetmap.org
>> >>>
>> >>> Ik heb het hier vooral over de individuele parkeerplaatsen bij die
>> >>> winkels, ingetekend door Jakka (hopelijk dezelfde als die van de mailing
>> >>> list hier ?).
>> >>> Ik bedoel: dit is gewoon kaartvervuiling, zet daar gewoon 1 area met
>> >>> amenity=parking en de kous is af.
>> >>>
>> >>> Plaatsen voor gehandicapten/PRM zou ik nog wel toelaten afzonderlijk in
>> >>> te tekenen, ook al omdat het anders moeilijk in een area te definiëren
>> >>> is waar men dan een tag "capacity:disabled" op zet. Dan weet je wel
>> >>> hoevéél er zijn, maar je weet niet wáár ze zich bevinden.
>> >>>
>> >>> Een zelfde opmerking aan de fetishisten die graag afzonderlijke bomen
>> >>> intekenen: stop er aub mee. Tenzij het echt een karakteristiek kenmerk
>> >>> is of een echte bomenrij staat ("Allee unter den Linden" in Berlijn om
>> >>> maar te zeggen), maar laat het anders gewoon zo. Er zijn betere zaken te
>> >>> mappen.
>> >>>
>> >>> Groeten,
>> >>>
>> >>> Denis
>> >>>
>> >>>
>> >>>
>> >>> 

Re: [OSM-talk-be] Overdreven gedetailleerde mapping ?

[Marc Gemis]

Karel,

Queries worden trager schrijf je. Zonder analyse van de server waarop
de queries uitgevoerd worden kan ik niet zeggen dat dit de schuld is
van de grote database.
Misschien zijn er meer queries, of meer complexe queries. Ik zie ook
niet goed hoe het toevoegen van een object X (bv. een klein
grasperkje) invloed kan hebben op het opvragen een onafhankelijk
object Y (bv. vliegvelden).

Details nemen plaats in.
Details hoeven niet gerenderd te worden (hoewel amenity=parking_space
wel getoond wordt), dus de invloed van details is enerzijds op de
centrale DB, anderzijds misschiebn op de grootte van de tiles.
Aangezien die details enkel op zoomlevel 19 of zo getoond worden,
worden enkel die tiles wat groter.
Dus niet echt een probleem volgens mij. Voor de centrale databank wil
men  naar de "nutteloze" nodes zonder tag kijken om iets aan de
grootte/performantie te doen. Die nodes zouden deel moeten uitmaken
van de weg en niet op zichzelf staan (zegt ment). Ik heb jammer genoeg
de voordracht op SOTM in dat verband nog niet bekeken.

Andere databanken (denk Nominatim) kunnen die "nutteloze" dingen er
van in het begin uitfilteren.
Verder zijn er hoe langer hoe meer grote bedrijven (denk Apple &
Facebook) die OSM gebruiken en waarschijnlijk we een deel van de
sponsering voor zich gaan nemen.

Als je wil vergelijken met Wikipedia, kijk dan ook eens naar Wikimedia
Commons, hoe groot moet die databank wel niet zijn met al die beelden
en video's. Volgens mij nemen die "iets" meer plaats in beslag dan een
node met wat tags.

We kunnen ook veel plaats beparen door (tongue in cheek)
- fietspaden/sidewalk als tags op weg,
- weglaten van busroutes (gebruik de app van de Lijn), fiets en wandel
routes (gebruik de wandelknooppunt app of iets dergelijks)
- luchthavens vervangen door nodes, welke weggebruiker moet er nu
weten waar de landingsbaan is
- huizen & addressen vervangen door 1 node, of zelfs adres nodes te
vervangen door interpollatie lijnen
- alle landuse weg te laten (wie moet er nu naar een weide navigeren)
- grenzen (die leiden  toch maar tot discussies)
- alles ivm met nutsvoorzieningen. (*)
enz.

Voor alles wat iemand belangrijk vindt en wil inbrengen kan je wel
argumenteren dat het nutteloos is, of beter in een andere DB staat, of
compacter kan gemapped worden.

(*) maar kijk eens hoe relatief populair de voorgestelde tagging
schemas voor pipeline markers, streetcabinets e.d. waren.

mvg

m

On Sun, Nov 3, 2019 at 8:03 PM Karel Adams  wrote:
>
> Marc,
>
> (parenthese over mijn conflict met DWG: ik besef dat ik niet altijd even
> correct heb gehandeld. En ik had er ook niet zo uitvoerig over moeten
> vertellen, alhier, inderdaad. Blijft de frustratie dat er op een
> verzoenend bericht mijnerzijds niet werd ingegaan, er kwam zelfs geen
> "neen", er kwam gewoon niks... Blijft mijn waarschuwing: "let wat gij
> doet, de DWG kan hard en niet altijd even konsekwent ingrijpen."
> Communicatie vooraf is erg belangrijk voor die lieden, en daar kan
> inderdaad niemand tegen zijn)
>
> Maar wat betreft "Ieder mapt wat hij/zij wil", daar heb ik twee
> bedenkingen bij:
>
> 1) we moeten de database niet nodeloos belasten. Er komt alsmaar
> informatie bij, de database groeit stevig, queries worden alsmaar
> trager. De capaciteit van de servers is niet onbeperkt, en er blijven
> ook geen sponsors gevonden worden om disken en memory bij te kopen. Ik
> ben beroepshalve bezig met serverinfrastructuur en het is een permanente
> ergernis dat er moet hardware worden toegevoegd (en dus geld worden
> uitgegeven) zonder dat het echt nodig is.
>
> 2) ik vergelijk OSM graag met wikipedia - ook dat is een project dat
> bouwt op open inbreng, nog opener dan OSM want men kan er zelfs
> bijdragen zonder een account aan te maken. Er verschijnt daar dan ook
> heel wat junk, en er is een gedefinieerde procedure om dat op te kuisen
> ("Article for Deletion"). Aan een dergelijke aanpak ontbreekt het bij
> OSM, en ik mis eraan. De huidige wollige aanpak kan nmbm niet blijven
> duren. Al dient het gezegd dat Wikipedia een encyclopedie maakt, en dus
> bewust en systematisch de lat hoog legt; en tegelijk veel zichtbaarder
> is, en dus veel meer blootgesteld aan vandalisme, waardoor er veel meer
> nood is aan procedures en strikte regels.
>
> Dank voor de openhartige en beleefde discussie!
>
> Karel
>
> On 11/2/19 9:45 PM, Marc Gemis wrote:
> > Ik sluit me volledig aan bij Jakka. Ieder mapt wat hij/zij wil.
> >
> > Het aantal parkeerplaatsen kan interessante info zijn, net zoals de
> > exacte ligging (misschien voor slechtzienden die over het terrein
> > moeten navigeren). Kleine bloemperken e.d. geven aan hoe groen een
> > stad is.
> >
> > Zo zijn er misschien ook mensen die zich afvragen wat het nut i

Re: [OSM-talk-be] Overdreven gedetailleerde mapping ?

[Marc Gemis]

Ik sluit me volledig aan bij Jakka. Ieder mapt wat hij/zij wil.

Het aantal parkeerplaatsen kan interessante info zijn, net zoals de
exacte ligging (misschien voor slechtzienden die over het terrein
moeten navigeren). Kleine bloemperken e.d. geven aan hoe groen een
stad is.

Zo zijn er misschien ook mensen die zich afvragen wat het nut is van
afzonderlijke fietspaden of landingsbanen op een vliegveld of om het
even welk topic dat jij wel belangrijk vindt.

Je hoort dit soort commentaren wel meer (en ik heb waarschijnlijk zelf
ook al wel die fout gemaakt, maar ik probeer ze niet terug te maken)
"ik vind dat X niet gemapped moet worden". OSM is een project met vele
gezichten en veel verschillend gebruik. Daar moet je mee leren leven.

Afhankelijk van wat Karel opkuisen noemt (verwijderen?), kan ik me
voorstellen de DWG hem op de vingers tikt. Mappen op een plek die je
niet kent brengt altijd gevaren met zich mee. Dit lijkt me een typisch
verhaal van wie zijn * verbrand, moet op de blaren zitten. Het is een
beetje raar dat hij eerst over opkuisen van bloemperken spreekt en dan
over technisch verkeerd.

mvg
& happy mapping van om het even wat je belangrijk vindt, (bij voorkeur
wel lokaal na survey ;-) )

On Sat, Nov 2, 2019 at 4:55 PM Jakka  wrote:
>
> Op 2/11/2019 om 14:37 schreef Denis Verheyden:
> > Dag allen,
> >
> > Na een tijdje inactiviteit ben ik opnieuw wat verbeteringen op OSM aan
> > het aanbrengen (kleine stukjes GRB-import, aanvullen of verbeteren
> > huidige situaties).
> > Echter kwam ik onlangs een geval tegen dat mijns inziens overdreven
> > gedetailleerde mapping is:
> >
> > https://www.openstreetmap.org/#map=19/50.99435/4.47499
> >
> > 
> >
> > OpenStreetMap 
> > OpenStreetMap is a map of the world, created by people like you and free
> > to use under an open license. Hosting is supported by UCL, Bytemark
> > Hosting, and other partners.. Learn More Start Mapping
> > www.openstreetmap.org
> >
> > Ik heb het hier vooral over de individuele parkeerplaatsen bij die
> > winkels, ingetekend door Jakka (hopelijk dezelfde als die van de mailing
> > list hier ?).
> > Ik bedoel: dit is gewoon kaartvervuiling, zet daar gewoon 1 area met
> > amenity=parking en de kous is af.
> >
> > Plaatsen voor gehandicapten/PRM zou ik nog wel toelaten afzonderlijk in
> > te tekenen, ook al omdat het anders moeilijk in een area te definiëren
> > is waar men dan een tag "capacity:disabled" op zet. Dan weet je wel
> > hoevéél er zijn, maar je weet niet wáár ze zich bevinden.
> >
> > Een zelfde opmerking aan de fetishisten die graag afzonderlijke bomen
> > intekenen: stop er aub mee. Tenzij het echt een karakteristiek kenmerk
> > is of een echte bomenrij staat ("Allee unter den Linden" in Berlijn om
> > maar te zeggen), maar laat het anders gewoon zo. Er zijn betere zaken te
> > mappen.
> >
> > Groeten,
> >
> > Denis
> >
> >
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
> >
>
> Denis,
>
> Wat betreft het detail micro mapping, niemand verplicht jou om zelfde te
> doen, voor parking_space mag dit volgens de wiki
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space.
> Maar als jij dat niet graag ziet kan ik er niet aandoen.
> Misschien een overdreven voorbeeld van jou boom ... geen volledige
> kenmerken, dan kan je dat voor alles en nog wat door trekken naar
> gebouwen zet jij er steeds het aantal verdiepen erbij ? het soort
> dak dat erop staat ? voor wegen welke correcte surface, als er voetpaden
> zijn, boordstenen enz...
>
> En zoals iemand al reageerde met opkuis van gemapte zaken betreft als
> deze er werkelijk aanwezig zijn dan mag dit beschouwd worden als
> vandalisme en daar zijn regels voor.
>
> We gaan daar geen inkt meer aan verspillen iedereen zijn ding en osm
> wordt er beter door.
>
> Happy mapping
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] tags for prohibitory road signs in Belgium

[Marc Gemis]

On Wed, Sep 25, 2019 at 9:27 PM Stijn Rombauts via Talk-be
 wrote:
> - A general remark that could be added: never follow the traffic signs 
> blindly when adding (access) tags: in some local authorities the one who has 
> to decide about traffic signs doesn't seem to know which sign to use where. 
> In the draft there is also a mistake: M4 and M5 cannot be added to a C1.

What about a C3 (no vehicles allowed) with a M-sign "Privaat weg"
(private road).
Would that mean that pedestrians can pass ?

Additional context: this road goes over a farmyard. It used to be part
of the node network in Blaasveld, but since that C3 appeared, the
route was changed and no longer passed over the farm yard.
It seems that they mean that nobody is allowed on that track, but the
sign does not properly communicate this I think.

Mapillary image: https://www.mapillary.com/map/im/YIk4nvPT2fLurKF_crSCrg

m.

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

Re: [OSM-talk-be] hidden official path vs. unofficial by-pass : consensus?

[Marc Gemis]

Seems my opinion is different from the other Marc.

AFAIK, the OSM consensus is to map what is on the ground, in this case
only the by-pass. You could keep the "official" path, with some tag
disused:highway or so, but IMHO, that is just clutter that makes it
harder for others to edit. When your local council does not bother to
re-instantiate the official path, it will soon loose that status, not?

As far as the removal of the "official" path is concerned, it probably
depends on what "official" means. If it is e.g. in the Atlas der
Buurtwegen and was not officially removed by the council, you should
contact your council and describe the problem. I did that once and the
day after, the track was open to the public again.

On Tue, Aug 20, 2019 at 8:59 PM Francois Gerin  wrote:
>
> Hi,
>
> Here is a probably subjective issue, that has certainly already been
> discussed, but I cant' find a search engine for the mailing archives.
>
> Problem:
> It's very frequent, in Belgium and certainly in many places, that a
> private or farmer steals a footway because he dislikes people pass there
> or just to extend his field for free.
> The **official** path is then often no more visible and, sometime, there
> may have an **unofficial** by-pass in the area.
> The official trace MUST be kept because, well... it is official. :-)
> And also because the by-pass MAY disappear at any time.
>
> Envisioned solutions:
> 1. Keep official path only.  =bad because it does not reflect the
> reality (which may stand for many years!)
> 2. Delete the official one, draw the by-pass. =rejected, because the
> official must be kept, or we may loose both
> 3. Keep both, but flag the hidden one with trail_visibility tag. =best
> option found up to now, which seems accepted widely+officially
>
> Questions:
> A. Is there any OSM consensus for a solution, at the global/worldwide
> community level?
> B. If not, is there any Belgian community consensus?
> C. If not, is there any widely accepted option?
> D. If not, is there any better solution than option 3?
>
> (Side issue: the current rendering on OSM does not express that this
> path is poorly visible. But at least the flag is there for other
> rendering tools/layouts.)
>
> Two examples I had to do:
> https://www.openstreetmap.org/way/700172645
> https://www.openstreetmap.org/way/629096505
>
> Thank you in advance for any pointer/doc/wiki/consensus! :-)
>
> Regards,
> François
> (aka fgerin on OSM)
> (aka fge1 on balnam)
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Ways with identical coordinates on top of each other

[Marc Gemis]

I assume OSM always has been a 2.5D map. I'm thinking about tunnels
and bridges. To properly map them, we always needed the level tag. So
any data consumer that creates a road network from OSM will need to
have knowledge about the level tag.
Of course, the example that you mention, of indoor mapping with
multiple levels, is not properly solved by carto-css (the default
rendering on osm.org). The problem will also occur for POIs on
different floors. People have been experimenting with other
representations to make this type of data understandable.
I guess more and more 3D features will be added to the data, the
question is how fast will the data consumers come up with
representations that are easy to understand.

regards

m.

On Thu, Aug 8, 2019 at 12:22 PM Florian Goetghebeur
 wrote:
>
> Hello,
>
> I recently came across a parking building with multiple floors in OSM, in 
> which ways are tagged with 'level' and 'layer' tags. It struck me that there 
> are ways that have the very same geometry on different levels (see links 
> below). As a result, the map has four arrows (one for each level), indicating 
> the oneway direction, with only little space in between. It looks strange to 
> me. But having nodes and ways stacked on top of each other might have other 
> unwanted consequences, e.g. when you try to process the OSM data to get a 
> road network for routing and you do not take the level and layer tags into 
> account.
>
> So I am now wondering about the community's vision about this 2D vs 3D issue. 
> Can OSM still be seen as a 2D map? In what way is OSM evolving regarding this 
> topic? We now have this strange blend between a 2D visualization and a few 3D 
> tags that can cause issues. The notes and comments for the nodes below show 
> that there have been problems already.
>
> Thanks for sharing your insights!
>
> Four nodes at the same location:
> https://www.openstreetmap.org/node/4359171125
> https://www.openstreetmap.org/node/4359171126
> https://www.openstreetmap.org/node/4359171127
> https://www.openstreetmap.org/node/4359171128
> Two ways with the exact same coordinates:
> https://www.openstreetmap.org/way/438182278
> https://www.openstreetmap.org/way/438182283
>
> Kind regards,
> Florian
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] bridge or tunnel?

[Marc Gemis]

additional things that can be part of the definition:
 - passages through embankments are (in general) not tunnels.
- when a road passes over another one, located in a cutting, does not
place the lower one in a tunnel (Antwerp ring road)
- when the road goes under a waterway, the road is in a tunnel

Again: exceptions will exist and they have to be seen as a rule of
thumb, not a hard definition.

On Wed, May 29, 2019 at 5:46 AM Marc Gemis  wrote:
>
> AFAIK the tunnel=building_passage, this is not a tunnel, but using the
> tunnel tag anyway. I guess the same is true for culvert. I would not
> try to come up with a definition that is also applicable to those 2.
>
> Maybe my rule of thumb could be extended somehow for the metrotunnels,
> which are clearly underground, and are therefore tunnels. For the mole
> pipes, you write "dug out and covered", which is another indication
> that it is a tunnel.
>
> That being said, I guess you will never find a definition that works
> 100% of the time, because the real world is just messy.
>
> On Tue, May 28, 2019 at 11:57 PM Stijn Rombauts via Talk-be
>  wrote:
> >
> > Hi,
> >
> > First: the interpretations given here to 'tunnel' are much more strict than 
> > the wiki, which leaves much more room for interpretation. A strict 
> > interpretation of tunnel makes the use of tunnel=yes of tunnel=culvert for 
> > passages of rivers underneath a road senseless, just as 
> > tunnel=building_passage.
> >
> > Second, I hope that you are aware of the consequences of your 
> > interpretations. Let's use the definition of Marc, which is the most 
> > elaborated: "I apply the rule: stand on the road, look up, which layers of 
> > material do you "see" before you reach the sky? Is there earth 
> > (grond/aarde) that was not placed there artificially, then you are in a 
> > tunnel.": Then the 'railroad tunnel' between Brussels North and Brussels 
> > South is NOT a tunnel. It is just a mole pipe (in the words of Gerard). The 
> > whole thing is dug out, built and then covered with streets, buildings and 
> > here there a bit of gorund.
> > Even a lot of the metrotunnels are made with the 'cut and cover' technique 
> > and are thus NO tunnels? Ecoduct Kikbeekbron over the E314 is NOT a tunnel?
> > Also the examples given by Marc and Tim with such a thin cover are most 
> > likely made 'cut and cover' and have only 'artificial' things overneath: NO 
> > tunnels...
> > And what do you do with the GEN-constructions at railway 161 in Genval? The 
> > railway has been covered with roads and parking lots. Also no tunnels?
> > On the other hand: ecoduct Groenendaal really looks like a bridge but has 
> > been mapped as a tunnel...
> >
> > Lionel said : "A tunnel is generally something that was dig (removing 
> > earth/material) and consolidated from the inside (most often with concrete) 
> > like a subway tunnel if you want. It seems pretty rare to dig a big hole, 
> > make a tunnel and put back the earth on top !": Yet, that ís a very common 
> > practice...
> >
> > So to me these seem to be useless definitions...
> >
> > Or does the word 'artificial' means that ground level matters? The ringway 
> > around Antwerp (R1) is almost everywhere at level -1, below ground level. 
> > The cutting is here the artificial structure (using Yves' words this time). 
> > So where there is a road going overneath, the ringway goes through a 
> > tunnel...? The same for Joost's example: if you look at the aerial imagery, 
> > you can see clearly they had to dig out the N28 to get underneath the 
> > railway and the other roads: thus a tunnel...? And what about the complex 
> > traffic changers where it is often very hard to see what the original 
> > ground level was.
> >
> > @ Yves: 'Layer' gives a relative position. Something at ground level can 
> > perfectly have layer=-1 or layer=1. Check the wiki. And further: a bridge 
> > with layer = 1 doesn't mean it is above ground level; a tunnel with layer = 
> > -1 doesn't mean it is below ground level.
> >
> > @ Tim: What came first is a useless criterion. The E313 was constructed 
> > before the E314, but it is definitely a bridge of the E313 above the E314. 
> > And the definitions of bridge or a tunnel should be so that anyone knows 
> > whether to map things as bridge or tunnel without having to know in which 
> > order roads, railways, etc. were constructed.
> >
> > So can someone can come up with a useful definition?
> >

Re: [OSM-talk-be] bridge or tunnel?

[Marc Gemis]

AFAIK the tunnel=building_passage, this is not a tunnel, but using the
tunnel tag anyway. I guess the same is true for culvert. I would not
try to come up with a definition that is also applicable to those 2.

Maybe my rule of thumb could be extended somehow for the metrotunnels,
which are clearly underground, and are therefore tunnels. For the mole
pipes, you write "dug out and covered", which is another indication
that it is a tunnel.

That being said, I guess you will never find a definition that works
100% of the time, because the real world is just messy.

On Tue, May 28, 2019 at 11:57 PM Stijn Rombauts via Talk-be
 wrote:
>
> Hi,
>
> First: the interpretations given here to 'tunnel' are much more strict than 
> the wiki, which leaves much more room for interpretation. A strict 
> interpretation of tunnel makes the use of tunnel=yes of tunnel=culvert for 
> passages of rivers underneath a road senseless, just as 
> tunnel=building_passage.
>
> Second, I hope that you are aware of the consequences of your 
> interpretations. Let's use the definition of Marc, which is the most 
> elaborated: "I apply the rule: stand on the road, look up, which layers of 
> material do you "see" before you reach the sky? Is there earth (grond/aarde) 
> that was not placed there artificially, then you are in a tunnel.": Then the 
> 'railroad tunnel' between Brussels North and Brussels South is NOT a tunnel. 
> It is just a mole pipe (in the words of Gerard). The whole thing is dug out, 
> built and then covered with streets, buildings and here there a bit of gorund.
> Even a lot of the metrotunnels are made with the 'cut and cover' technique 
> and are thus NO tunnels? Ecoduct Kikbeekbron over the E314 is NOT a tunnel?
> Also the examples given by Marc and Tim with such a thin cover are most 
> likely made 'cut and cover' and have only 'artificial' things overneath: NO 
> tunnels...
> And what do you do with the GEN-constructions at railway 161 in Genval? The 
> railway has been covered with roads and parking lots. Also no tunnels?
> On the other hand: ecoduct Groenendaal really looks like a bridge but has 
> been mapped as a tunnel...
>
> Lionel said : "A tunnel is generally something that was dig (removing 
> earth/material) and consolidated from the inside (most often with concrete) 
> like a subway tunnel if you want. It seems pretty rare to dig a big hole, 
> make a tunnel and put back the earth on top !": Yet, that ís a very common 
> practice...
>
> So to me these seem to be useless definitions...
>
> Or does the word 'artificial' means that ground level matters? The ringway 
> around Antwerp (R1) is almost everywhere at level -1, below ground level. The 
> cutting is here the artificial structure (using Yves' words this time). So 
> where there is a road going overneath, the ringway goes through a tunnel...? 
> The same for Joost's example: if you look at the aerial imagery, you can see 
> clearly they had to dig out the N28 to get underneath the railway and the 
> other roads: thus a tunnel...? And what about the complex traffic changers 
> where it is often very hard to see what the original ground level was.
>
> @ Yves: 'Layer' gives a relative position. Something at ground level can 
> perfectly have layer=-1 or layer=1. Check the wiki. And further: a bridge 
> with layer = 1 doesn't mean it is above ground level; a tunnel with layer = 
> -1 doesn't mean it is below ground level.
>
> @ Tim: What came first is a useless criterion. The E313 was constructed 
> before the E314, but it is definitely a bridge of the E313 above the E314. 
> And the definitions of bridge or a tunnel should be so that anyone knows 
> whether to map things as bridge or tunnel without having to know in which 
> order roads, railways, etc. were constructed.
>
> So can someone can come up with a useful definition?
>
> Can I come up with a definition? I like the length/width ratio, the open 
> bridge(like) structure against a confined tunnel(like) structure. And the 
> fuzziness of the wiki. But one thing is very clear for me: ground level 
> doesn't matter.
>
> Regards,
>
> StijnRR
>
>
>
> Op dinsdag 28 mei 2019 18:52:50 CEST schreef Marc Gemis 
> :
>
>
> This is the place:
> https://www.google.com/maps/@51.2216551,4.0345363,3a,75y,49.39h,77.96t/data=!3m6!1e1!3m4!1sjggCIzrpgLhVFtrn6gYCnQ!2e0!7i13312!8i6656
> (sorry no Mapillary images yet).
>
> Burchtakker (the parallel road) is lowered near the (bicycle) tunnel
> under the E34/A11.
>
> On Tue, May 28, 2019 at 6:36 PM Marc Gemis  wrote:
> >
> > I think there is a tunnel under  the e34 between Ant

Re: [OSM-talk-be] bridge or tunnel?

[Marc Gemis]

This is the place:
https://www.google.com/maps/@51.2216551,4.0345363,3a,75y,49.39h,77.96t/data=!3m6!1e1!3m4!1sjggCIzrpgLhVFtrn6gYCnQ!2e0!7i13312!8i6656
(sorry no Mapillary images yet).

Burchtakker (the parallel road) is lowered near the (bicycle) tunnel
under the E34/A11.

On Tue, May 28, 2019 at 6:36 PM Marc Gemis  wrote:
>
> I think there is a tunnel under  the e34 between Antwerpen en Zelzate.  There 
> used to be a level crossing which was removed and instead they created an 
> underground passage for it.
>
> M
>
> Op di 28 mei 2019 14:46 schreef Lionel Giard :
>>
>> @joost schouppe  To me that's indeed a bridge, as you see the same structure 
>> as on the motorway bridges : a platform supported by pillars
>>
>> A tunnel is generally something that was dig (removing earth/material) and 
>> consolidated from the inside (most often with concrete) like a subway tunnel 
>> if you want. It seems pretty rare to dig a big hole, make a tunnel and put 
>> back the earth on top ! ;-)
>>
>> I can't find example of tunnels that's really like "under a railway or 
>> motorway", so i would say that probably 99% of the tunnel are below ground 
>> or mountains/hills (if we exclude the obvious building passage that we 
>> classify as tunnel in OSM). They are generally longer than wide as someone 
>> quoted from wikipedia.
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] bridge or tunnel?

[Marc Gemis]

I think there is a tunnel under  the e34 between Antwerpen en Zelzate.
There used to be a level crossing which was removed and instead they
created an underground passage for it.

M

Op di 28 mei 2019 14:46 schreef Lionel Giard :

> @joost schouppe   To me that's indeed a bridge,
> as you see the same structure as on the motorway bridges : a platform
> supported by pillars
>
> A tunnel is generally something that was dig (removing earth/material) and
> consolidated from the inside (most often with concrete) like a subway
> tunnel if you want. It seems pretty rare to dig a big hole, make a tunnel
> and put back the earth on top ! ;-)
>
> I can't find example of tunnels that's really like "under a railway or
> motorway", so i would say that probably 99% of the tunnel are below ground
> or mountains/hills (if we exclude the obvious building passage that we
> classify as tunnel in OSM). They are generally longer than wide as someone
> quoted from wikipedia.
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] bridge or tunnel?

[Marc Gemis]

I doubt one had to dig something for the road to pass under the
railway. There is no "earth" between the road and the sky, only stuff
that humans created, like concrete, stones and asphalt. So a bridge
for me.
I apply the rule: stand on the road, look up, which layers of material
do you "see" before you reach the sky? Is there earth (grond/aarde)
that was not placed there artificially, then you are in a tunnel.
(similar to the digging rule mentioned earlier).

m.

On Tue, May 28, 2019 at 12:29 PM joost schouppe
 wrote:
>
> Hmm, how about this case:
>
> https://play.osm.be/historischekaart.html#18/50.84125/4.03590/dhm_hill-osmroads
> https://www.mapillary.com/app/?lat=50.8409878896054&lng=4.035847194701205&z=17&pKey=CemcYfldMKwaCCdn0eK2bQ&focus=photo&x=0.5005982815044207&y=0.34925403860156434&zoom=0
>
> It's a road that was dug under a slightly raised train track, but it looks 
> like a bridge. Or is it bridge for the road, tunnel under the train, bridge 
> again :) ?
>
> Joost Schouppe
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] save-the-internet - manifestaties nu zaterdag 23 maart

[Marc Gemis]

I left a comment on his changeset.

regards

m.

p.s please leave a message as soon as you see a changeset that is
using any Google component as source.

On Sat, Mar 23, 2019 at 11:11 AM Stijn Rombauts via Talk-be
 wrote:
>
> And if you look at this object and its source tag, OSM is in trouble...
> https://www.openstreetmap.org/way/567560764
>
> StijnRR
>
> Op vrijdag 22 maart 2019 15:12:07 CET schreef Marc Gemis 
> :
>
>
> Mogelijks zou ook OpenStreetMap een filter moeten installeren om te
> kijken dat de data die we uploaden niet onder een of andere copyright
> valt. Het gaat niet enkel om foto's, fillms of muziek. Er is ook nog
> een ander artikel dat bepaalde beperkingen gaat opleggen aan links. Je
> zou niet meer zo maar een link naar een krantenartikel of zo op je
> website mogen plaatsen geloof ik.
>
> Ik denk dat het vooral de bedoeling is om mensen bewust te maken dat
> men probeert de vrijheid van meningsuiting aan banden te leggen. Ook
> zouden vooral kleinere, innovatieve bedrijfjes getroffen worden, omdat
> zo'n uploadfilters heel lastig zijn om  te ontwikkelen (of duur om aan
> te kopen)
>
> En dan nog, het zal heel moeilijk zijn voor zo'n filters om het
> onderscheid te maken tussen een filmpje van iemand die thuis op een
> piano heel goed een klassiek stuk opvoert en een gelijkaardige, onder
> copyright vallende uitvoering van een professioneel artist.
>
> Ook is er de vrees dat satire e.d. aan de hand van foto's van bekende
> personen (denk politiekers) nog mogelijk zal zijn.
>
> Een van de grootste voorstanders van de nieuwe wetgeving, is deze pipo
> (excusez-le-mot): https://twitter.com/AxelVossMdEP
>
> m
>
> On Fri, Mar 22, 2019 at 2:52 PM Karel Adams  wrote:
> >
> > ** texte Français ci-dessous **
> >
> > Dankje, Marc. Misschien had ik er moeten bij vertellen dat ik op de link
> > kwam door (op mijn kantoor-pc) de basiskaart te bezoeken op
> > openstreetmap.org/#map - er blijkt dus een zeker engagement te zijn
> > vanwege "de top van OSM" al weet ik dat dat een zeer relatief begrip is.
> >
> > Op de webstek die ik linkte vindt men inderdaad vooral manifestaties in
> > Duitsland, maar toch ook verschillende in Roemenië en in Polen, en nog
> > elders. Ik zou echt verwachten dat er ook in Brussel actie komt, het is
> > tenslotte hier dat het beslist wordt.
> >
> > Alleen is het verband met OSM me niet zo duidelijk, we kunnen toch niet
> > veel copyrighted spul uploaden behalve misschien foto's?
> >
> > Karel
> >
> > =
> >
> > Marc, merci. J'aurais du ajouter que je suis tombé sur cette histoire en
> > visitant notre propre carte "générique" sur www.openstreetmap.org/#map.
> > Il y aurait donc un certain support de la part des "hautes instances" de
> > OSM.
> >
> > Le site que j'indiquais mentionne surtout des manifestations en
> > Allemagne, de fait; mais il y en a aussi en Pologne, en Roumanie, et
> > ailleurs. Pourquoi alors pas à Bruxelles, où la décision sera prise?
> >
> > Seulement, je ne vois pas très bien le rapport de ces propos de loi avec
> > OSM - quel contenu "copyrighted" pourrions-nous publier, sauf quelques
> > photographies?
> >
> > =
> >
> >
> > On 22/03/2019 13:14, Marc Gemis wrote:
> > > In Duitsland zijn er al verschillende manifestaties tegen article 13 
> > > geweest.
> > > Mocht je Duits verstaan, deze dame [1] voert al enkele maanden
> > > opositie tegen het wetsvoorstel dat alle websites zal verplichten een
> > > filter te installeren om te kijken of er geen inhoud met licentie
> > > wordt geupload. Blijkbaar bestaat de lobby voor het artikel o.a. uit
> > > mediagroepen die nu politiekers al onder druk zetten mochten ze tegen
> > > het voorstel.
> > >
> > >
> > > [1] https://twitter.com/Senficon af en toe ook in het Engels.
> > >
> > > On Thu, Mar 21, 2019 at 7:36 PM Karel Adams  wrote:
> > >> Met enige verbazing zag ik de aankondiging van manifestaties overmorgen
> > >> zaterdag, tegen een wetgevend initiatief op Europees niveau. Nog
> > >> verbazender dat ik er nog niet van hoorde langs enige andere weg, bv.
> > >> alhier.
> > >>
> > >> https://savetheinternet.info/demos
> > >>
> > >> Drie mogelijkheden:
> > >>
> > >> * dit is niet ernstig
> > >>
> > >> * dit is ernstig, en er w

Re: [OSM-talk-be] save-the-internet - manifestaties nu zaterdag 23 maart

[Marc Gemis]

Mogelijks zou ook OpenStreetMap een filter moeten installeren om te
kijken dat de data die we uploaden niet onder een of andere copyright
valt. Het gaat niet enkel om foto's, fillms of muziek. Er is ook nog
een ander artikel dat bepaalde beperkingen gaat opleggen aan links. Je
zou niet meer zo maar een link naar een krantenartikel of zo op je
website mogen plaatsen geloof ik.

Ik denk dat het vooral de bedoeling is om mensen bewust te maken dat
men probeert de vrijheid van meningsuiting aan banden te leggen. Ook
zouden vooral kleinere, innovatieve bedrijfjes getroffen worden, omdat
zo'n uploadfilters heel lastig zijn om  te ontwikkelen (of duur om aan
te kopen)

En dan nog, het zal heel moeilijk zijn voor zo'n filters om het
onderscheid te maken tussen een filmpje van iemand die thuis op een
piano heel goed een klassiek stuk opvoert en een gelijkaardige, onder
copyright vallende uitvoering van een professioneel artist.

Ook is er de vrees dat satire e.d. aan de hand van foto's van bekende
personen (denk politiekers) nog mogelijk zal zijn.

Een van de grootste voorstanders van de nieuwe wetgeving, is deze pipo
(excusez-le-mot): https://twitter.com/AxelVossMdEP

m

On Fri, Mar 22, 2019 at 2:52 PM Karel Adams  wrote:
>
> ** texte Français ci-dessous **
>
> Dankje, Marc. Misschien had ik er moeten bij vertellen dat ik op de link
> kwam door (op mijn kantoor-pc) de basiskaart te bezoeken op
> openstreetmap.org/#map - er blijkt dus een zeker engagement te zijn
> vanwege "de top van OSM" al weet ik dat dat een zeer relatief begrip is.
>
> Op de webstek die ik linkte vindt men inderdaad vooral manifestaties in
> Duitsland, maar toch ook verschillende in Roemenië en in Polen, en nog
> elders. Ik zou echt verwachten dat er ook in Brussel actie komt, het is
> tenslotte hier dat het beslist wordt.
>
> Alleen is het verband met OSM me niet zo duidelijk, we kunnen toch niet
> veel copyrighted spul uploaden behalve misschien foto's?
>
> Karel
>
> =
>
> Marc, merci. J'aurais du ajouter que je suis tombé sur cette histoire en
> visitant notre propre carte "générique" sur www.openstreetmap.org/#map.
> Il y aurait donc un certain support de la part des "hautes instances" de
> OSM.
>
> Le site que j'indiquais mentionne surtout des manifestations en
> Allemagne, de fait; mais il y en a aussi en Pologne, en Roumanie, et
> ailleurs. Pourquoi alors pas à Bruxelles, où la décision sera prise?
>
> Seulement, je ne vois pas très bien le rapport de ces propos de loi avec
> OSM - quel contenu "copyrighted" pourrions-nous publier, sauf quelques
> photographies?
>
> =
>
>
> On 22/03/2019 13:14, Marc Gemis wrote:
> > In Duitsland zijn er al verschillende manifestaties tegen article 13 
> > geweest.
> > Mocht je Duits verstaan, deze dame [1] voert al enkele maanden
> > opositie tegen het wetsvoorstel dat alle websites zal verplichten een
> > filter te installeren om te kijken of er geen inhoud met licentie
> > wordt geupload. Blijkbaar bestaat de lobby voor het artikel o.a. uit
> > mediagroepen die nu politiekers al onder druk zetten mochten ze tegen
> > het voorstel.
> >
> >
> > [1] https://twitter.com/Senficon af en toe ook in het Engels.
> >
> > On Thu, Mar 21, 2019 at 7:36 PM Karel Adams  wrote:
> >> Met enige verbazing zag ik de aankondiging van manifestaties overmorgen
> >> zaterdag, tegen een wetgevend initiatief op Europees niveau. Nog
> >> verbazender dat ik er nog niet van hoorde langs enige andere weg, bv.
> >> alhier.
> >>
> >> https://savetheinternet.info/demos
> >>
> >> Drie mogelijkheden:
> >>
> >> * dit is niet ernstig
> >>
> >> * dit is ernstig, en er wordt ook bij ons gemanifesteerd. Zoja: waar?
> >> wanneer?
> >>
> >> * dit is ernstig, en er is nog niks georganiseerd. Zoja, zullen we
> >> afspreken in Brussel, nu zaterdag? Ik ben alvast graag beschikbaar.
> >>
> >>
> >>
> >>
> >> ___
> >> Talk-be mailing list
> >> Talk-be@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-be
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] save-the-internet - manifestaties nu zaterdag 23 maart

[Marc Gemis]

In Duitsland zijn er al verschillende manifestaties tegen article 13 geweest.
Mocht je Duits verstaan, deze dame [1] voert al enkele maanden
opositie tegen het wetsvoorstel dat alle websites zal verplichten een
filter te installeren om te kijken of er geen inhoud met licentie
wordt geupload. Blijkbaar bestaat de lobby voor het artikel o.a. uit
mediagroepen die nu politiekers al onder druk zetten mochten ze tegen
het voorstel.


[1] https://twitter.com/Senficon af en toe ook in het Engels.

On Thu, Mar 21, 2019 at 7:36 PM Karel Adams  wrote:
>
> Met enige verbazing zag ik de aankondiging van manifestaties overmorgen
> zaterdag, tegen een wetgevend initiatief op Europees niveau. Nog
> verbazender dat ik er nog niet van hoorde langs enige andere weg, bv.
> alhier.
>
> https://savetheinternet.info/demos
>
> Drie mogelijkheden:
>
> * dit is niet ernstig
>
> * dit is ernstig, en er wordt ook bij ons gemanifesteerd. Zoja: waar?
> wanneer?
>
> * dit is ernstig, en er is nog niks georganiseerd. Zoja, zullen we
> afspreken in Brussel, nu zaterdag? Ik ben alvast graag beschikbaar.
>
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Looking how tagging "ijskelder"

[Marc Gemis]

There is a proposal for cellar entries that mentions icehouse:
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:man_made%3Dcellar_entrance
Just as with caves, it's easy to map the entrance, but harder to map the inside.

m

On Thu, Mar 21, 2019 at 1:05 PM Jakka  wrote:
>
> https://nl.wikipedia.org/wiki/IJskelder
> de ijskelder (m)the icehouse
> ijskelder   ice cellar ; snow cellar
> Nothing on tag info ?
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] how to create a 'ready-to-print' city map from OSM

[Marc Gemis]

As Jo wrote labelling will be difficult. Did you consider to create 2
maps, one in French and one in Dutch? (and perhaps one in German). Is
there a particular reason to create a bi-lingual map?

m.

On Wed, Mar 6, 2019 at 9:53 AM PONCELET Nadia (Firebru)
 wrote:
>
> Hello everyone,
>
>
>
> I would like to create some map from OSM that could be printed on paper at 
> the approximate scale of 1:5000 and where all street names would appear on 
> the map and be easy to read.
>
>
>
> This is quite tricky I think, especially for Brussels where street names 
> usually have a french and a dutch version. I have already done this exercise 
> previously using UrbIS and I had to use some tricks such as shortening the 
> names by combining the french and dutch versions when possible (e.g. "Rue de 
> l'Ommegangstr." or "Quai F. Demetskaai") and widen the streets. I don't care 
> that the streets are no more "at scale", the important is that all (or most) 
> street names are legible. The rendering is similar to De Rouck map guides or 
> 'Bruxelles en poche' for those who know these books. In long streets, the 
> name can also be repeated several times.
>
>
>
> My final result from UrbIS was more or less satisfactory (even if it still 
> required some workforce to displace manually a few toponyms at the end) but I 
> would like to be able to create the same kind of map from OSM for a larger 
> area than the Brussels Region and also be able to update it periodically.
>
>
>
> Before I start working on this, would you have some advice or know any 
> people/projects/tools/libraries/ideas that could be a source of inspiration 
> (maybe from ‘OSM on paper’ wiki page)?
>
>
>
> Thank you very much for your answers.
>
>
>
> Nadia
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] JOSM shared boundary of area

[Marc Gemis]

I think I have only seen a warning with landcover areas, as JOSM does
not really know that type of objects.

What are the tags you place on the "boundary"? You will never see this
warning on 2 connected buildings.
If you are mapping admin boundaries, you should use relations and have
the common way in both relations.

You can use the extrude functionality to draw two areas that share a
common way, see
https://josm.openstreetmap.de/wiki/Help/Action/Extrude.
Especially the little movie on the houses, but keep the "alt"-key
pressed during the extrude action (on a Mac).

m.

On Wed, Mar 6, 2019 at 11:28 AM Gerard Vanderveken  wrote:
>
> Hi,
>
> I'm a bit in trouble with shared boundaries of area. I try to sketch the
> situation.
> I have a square area and create a rectangle nearby with the same width
> and half the height, starting at the bottom right, drawing a line to the
> right, up to half the height, back to the left half way the side of the
> square and then down to the starting point. The third point is linked to
> the square side by tools - join node to way. This creates a double line
> in the boundary and you get a warning when saving.
>
> Obvious, this is not the right way to do it:
> - What should be the right procedure?
> - When you have the above situation, what is the easiest way to correct
> it? There is a function to merge 2 points to 1, but is there also one to
> merge 2 identical lines?
>
> Regards,
> Gerard
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

[OSM-talk-be] Fwd: Vraag workshop OSM voor Pasar GPS-trefdag van 19 oktober 2019

[Marc Gemis]

Hallo,

is er iemand geïnteresseerd om hier een voordacht te gaan geven ?

mvg

m

-- Forwarded message -
From: Alain Segers 
Date: Mon, Jan 14, 2019 at 5:23 PM
Subject: Vraag workshop OSM voor Pasar GPS-trefdag van 19 oktober 2019
To: commun...@osm.be 


Beste,



Met vrijetijdsorganisatie Pasar VZW organiseren we op *zaterdag 19 oktober
2019* voor onze GPS-vrijwilligers en andere GPS-liefhebbers een nationale
GPS-trefdag in Sint-Niklaas.  Het is vooral een ontmoetingsmoment voor onze
GPS-vrijwilligers waar ze naast onderlinge kennisuitwisseling ook kunnen
deelnemen aan diverse GPS-workshops.  Vanaf 14u zouden we ook een geocache
workshop en geocache event voorzien.



Vorig jaar hadden we een workshop Garmin Basecamp, Osmand en Routeyou.
Voor 2019 zouden we graag iets aanbieden rond Openstreetmaps  zoals
bijvoorbeeld het updaten en corrigeren van kaarten, info over de
openstreetmaps  community in België, enz.  Daarom kwamen we bij jullie
terecht.  Kennen jullie iemand die een dergelijke workshop zou kunnen
geven?   Normaal gezien zou de workshop gepland kunnen worden van 9u15 tot
11u met een plaspauze van een 5-tal minuutjes.



Alvast bedankt om dit te willen bekijken. Jullie kunnen me altijd bereiken
per mail of  mijn gsm 0475 47 23 10.   Meer info over onze Gps-werking bij
Pasar vind je ook op www.pasar.be/gps



Vriendelijke groeten,

Alain



[image: cid:image001.gif@01D4A449.E12EB710]

*Alain* Segers

Coördinator Pasar Oost-Vlaanderen (Waas en Dender)
Coördinator Pasar Gps en Technologie voor Pasarafdelingen

*Pasar vzw – Oost-Vlaanderen *
Nieuwstraat 18A, 9100 Sint-Niklaas
tel. 0475 47 23 10 |www.pasar.be

[image: Beschrijving: Beschrijving: cid:image002.gif@01D009A7.000ACA80]Volg
ons op Facebook 

[image: Beschrijving: Beschrijving: cid:image002.gif@01D009A7.000ACA80]
Oost-Vlaanderen 

[image: pasar4] 



[image: cid:image005.gif@01D4A449.E12EB710]

[image: cid:image006.gif@01D4A449.E12EB710]
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Status GRB-import tool ?

[Marc Gemis]

dat is inderdaad een van de workarounds, maar voor de een of andere
reden bleef JOSM bij mij toch nog die tags doorsturen. Ik zal wel iets
verkeerd gedaan hebben.

m.

On Thu, Jan 24, 2019 at 8:33 PM Jo  wrote:
>
> Ik voel me ook niet geroepen om die rol op me te nemen, maar ik heb wel een 
> suggestie voor tags die niet mogen worden doorgestuurd.
>
> JOSM heeft daar ondersteuning voor.
>
> Wat ik gewoonlijk doe is zulke tags created_by of odbl noemen, aangezien die 
> al in de lijst staan.
>
> De andere mogelijkheid is een key (tags.discardable) in de instellingen 
> aanpassen en dan worden ze vanzelf weggegooid voordat er data naar de server 
> gaat.
>
> mvg,
>
> Jo
>
>
> On Thu, Jan 24, 2019 at 8:13 PM Marc Gemis  wrote:
>>
>> Hallo Denis,
>>
>> Ik had gehoopt dat iemand die dichter betrokken is bij de ontwikkeling
>> tijd zou hebben om je te beantwoorden, maar ze hebben het misschien te
>> druk momenteel.
>> Ik zal dan maar proberen te de situatie te schetsen:
>>
>> - de import mailing list had niet echt bezwaren, dus die hindernis is genomen
>> - de documentatie is volgens mij zo goed als af. De laatste beetjes
>> zouden tijdens een soort van kick-off meeting kunnen aangevuld worden
>> - de tool heeft nog 2 problem (voor zover ik weet)
>> * er komen nog extra tags mee die je niet mag uploaden. Daar bestaat
>> wel een eenvoudige workaround voor.
>> * niet alle adressen zijn correct. Vooral bij appartementsgebouwen met
>> meerdere huisnummers, zou het beter kunnen. Stel je hebt een gebouw
>> met 3 ingangen en huisnummers 15, 16 en 17.
>> Nu zal je 3 gebouwen met nummer 15-17 krijgen. Er is een mogelijkheid
>> om dit te verbeteren door een extra databank te laden in de tool. Dit
>> vraagt natuurlijk ontwikkelingstijd.
>>
>> Ik begrijp Glenn wel dat die wijziging echt noodzakelijk is voordat de
>> tool beschikbaar kan gemaakt worden. Als iemand die altijd klaagt over
>> foutieve data van externe bronnen, juich ik dat alleen maar toe.
>>
>> Ik weet echter niet of het enkel aan ons is om daarover te beslissen.
>>
>> Momenteel werkt ook Lodde1949 rustig verder aan het intekenen van
>> gebouwen adhv de GRB achtergrond en met de oude adres import tool. Dus
>> in een groot deel van de provincie Antwerpen is de tool al niet meer
>> zo relevant.
>>
>> Misschien moet er gewoon iemand een datum prikken, een zaal met
>> internet verbinding voorzien, iemand uitnodigen die de nodige
>> toelichtingen kan geven en de "import" officieel starten.
>> Het is duidelijk dat iemand de "projectleiderrol" op zich zal moeten
>> nemen om alles naast de ontwikkeling van de tool te organiseren en
>> daar dan ook voldoende tijd in stoppen.
>>
>> mvg
>>
>> m.
>>
>> p.s. Ik wil hier niemand met de vinger wijzen, we zijn allemaal
>> vrijwillers met beperkte tijd. Ikzelf heb ook geen tijd noch interesse
>> om deze rol op te nemen.
>>
>> On Sun, Jan 20, 2019 at 6:02 PM Denis Verheyden  wrote:
>> >
>> > Dag iedereen,
>> >
>> > Graag wou ik nog eens polsen wat de status is van de GRB-import tool. 
>> > Ergens in 2017 is de publieke versie uitgezet omdat veel mensen hiermee 
>> > onbedoelde of verkeerde wijzigingen hebben gedaan.
>> >
>> > Voor mij is deze tool echter het middel waarop ik wacht om nieuwe of 
>> > aangepaste gebouwen toe te voegen/wijzigen in OSM. Het heeft geen zin nu 
>> > gebouwen te tracen als we ze later opnieuw moeten vervangen door de 
>> > "officiële" geometrie van A(G)IV. Tot dan beperk ik mij enkel tot 
>> > toevoegen van nodes of features niet gerelateerd aan gebouwen.
>> >
>> > Groeten,
>> > Denis
>> > ___
>> > Talk-be mailing list
>> > Talk-be@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-be
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Status GRB-import tool ?

[Marc Gemis]

Hallo Denis,

Ik had gehoopt dat iemand die dichter betrokken is bij de ontwikkeling
tijd zou hebben om je te beantwoorden, maar ze hebben het misschien te
druk momenteel.
Ik zal dan maar proberen te de situatie te schetsen:

- de import mailing list had niet echt bezwaren, dus die hindernis is genomen
- de documentatie is volgens mij zo goed als af. De laatste beetjes
zouden tijdens een soort van kick-off meeting kunnen aangevuld worden
- de tool heeft nog 2 problem (voor zover ik weet)
* er komen nog extra tags mee die je niet mag uploaden. Daar bestaat
wel een eenvoudige workaround voor.
* niet alle adressen zijn correct. Vooral bij appartementsgebouwen met
meerdere huisnummers, zou het beter kunnen. Stel je hebt een gebouw
met 3 ingangen en huisnummers 15, 16 en 17.
Nu zal je 3 gebouwen met nummer 15-17 krijgen. Er is een mogelijkheid
om dit te verbeteren door een extra databank te laden in de tool. Dit
vraagt natuurlijk ontwikkelingstijd.

Ik begrijp Glenn wel dat die wijziging echt noodzakelijk is voordat de
tool beschikbaar kan gemaakt worden. Als iemand die altijd klaagt over
foutieve data van externe bronnen, juich ik dat alleen maar toe.

Ik weet echter niet of het enkel aan ons is om daarover te beslissen.

Momenteel werkt ook Lodde1949 rustig verder aan het intekenen van
gebouwen adhv de GRB achtergrond en met de oude adres import tool. Dus
in een groot deel van de provincie Antwerpen is de tool al niet meer
zo relevant.

Misschien moet er gewoon iemand een datum prikken, een zaal met
internet verbinding voorzien, iemand uitnodigen die de nodige
toelichtingen kan geven en de "import" officieel starten.
Het is duidelijk dat iemand de "projectleiderrol" op zich zal moeten
nemen om alles naast de ontwikkeling van de tool te organiseren en
daar dan ook voldoende tijd in stoppen.

mvg

m.

p.s. Ik wil hier niemand met de vinger wijzen, we zijn allemaal
vrijwillers met beperkte tijd. Ikzelf heb ook geen tijd noch interesse
om deze rol op te nemen.

On Sun, Jan 20, 2019 at 6:02 PM Denis Verheyden  wrote:
>
> Dag iedereen,
>
> Graag wou ik nog eens polsen wat de status is van de GRB-import tool. Ergens 
> in 2017 is de publieke versie uitgezet omdat veel mensen hiermee onbedoelde 
> of verkeerde wijzigingen hebben gedaan.
>
> Voor mij is deze tool echter het middel waarop ik wacht om nieuwe of 
> aangepaste gebouwen toe te voegen/wijzigen in OSM. Het heeft geen zin nu 
> gebouwen te tracen als we ze later opnieuw moeten vervangen door de 
> "officiële" geometrie van A(G)IV. Tot dan beperk ik mij enkel tot toevoegen 
> van nodes of features niet gerelateerd aan gebouwen.
>
> Groeten,
> Denis
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Fwd: Open Belgium 2019: Call for Speakers + Early Bird Tickets!

[Marc Gemis]

Thanks Dries & Jonathan for explaining it.
Too bad I cannot come to those days.

Perhaps there will be a SOTM-be or so later on this year ?

m.

On Thu, Jan 10, 2019 at 11:41 AM Dries Van Ransbeeck 
wrote:

> Yes, Open Belgium 2019 will consist of 2 days this year:
>
>- Community day on the worldwide Open Data Day
><http://opendataday.org/>
>- Saturday 2 March 2019 at BeCentral
>   - Mainly workshops
>   - Free of charge
>   - We'll announce this event next week
>   - Professional conference day
>- Monday 4 March 2019 at Herman Teirlinck
>   - Mainly presentations
>   - With lunch, coffee break, ... so we need to sell tickets
>   - Call for speakers open till the end of this week:
>   http://2019.openbelgium.be/speakers
>
> Best regards,
>
> Dries
>
>
> --
>
> Coordinator
> Open Knowledge Belgium <http://www.openknowledge.be/>
> @OpenKnowledgeBE <https://twitter.com/OpenKnowledgeBE> - @DVRansbeeck
> <https://twitter.com/DVRansbeeck>
> m: +32 474 26 56 18
>
>
>
> On Wed, 9 Jan 2019 at 21:04, Marc Gemis  wrote:
>
>> I'm a bit confused about
>>
>> - Open Belgium (on March 4)
>> and
>> - We will also organize a community day during the weekend this year
>>
>> which weekend is that ? Which community (OpenBelgium or OSM or both) ?
>>
>> I was also thinking (for a OSM public) -- at least I would be interested
>> to participate in such a workshop/presentation to learn more.
>>
>> - Improve your armchair mapping with Mapillary and OpenStreetCam
>>   Explain the 2 project, techniques to use them in iD or JOSM, filter
>> images on "topic", ...
>> - Wikidata (and Wikipedia and Commons) for mappers.
>> What is Wikidata, how can you edit, how can you put data in OSM,
>> potential ideas for using a joined DB.
>>
>>
>> m.
>>
>>
>> On Wed, Jan 9, 2019 at 5:18 PM Jonathan Beliën  wrote:
>>
>>> That’s a really awesome idea indeed !
>>> Thanks Marc !
>>>
>>>
>>>
>>> I’ll see if we can make that happen during OpenBelgium Community Day !
>>> \o/
>>>
>>>
>>>
>>> Jonathan Beliën
>>> SPRL GEO-6 <https://geo6.be/>
>>>
>>>
>>>
>>> *De :* Santens Seppe 
>>> *Envoyé :* mercredi 9 janvier 2019 09:27
>>> *À :* OpenStreetMap Belgium 
>>> *Objet :* Re: [OSM-talk-be] Fwd: Open Belgium 2019: Call for Speakers +
>>> Early Bird Tickets!
>>>
>>>
>>>
>>> Cool idea, Marc!
>>>
>>>
>>>
>>> *Van:* Marc Gemis [mailto:marc.ge...@gmail.com]
>>> *Verzonden:* dinsdag 8 januari 2019 20:32
>>> *Aan:* OpenStreetMap Belgium
>>> *Onderwerp:* Re: [OSM-talk-be] Fwd: Open Belgium 2019: Call for
>>> Speakers + Early Bird Tickets!
>>>
>>>
>>>
>>> I cannot make it to Open Belgium, but I have been thinking about a
>>> "walking meetup" for some time now. So instead of sitting in a pub, doing a
>>> walk and talk about OSM and survey techniques and apply them.
>>>
>>> Taking that idea, on a community day, it could be a workshop about
>>> surveying techniques, JOSM tips, micromapping, that kind of stuff. It would
>>> be an hand-on workshop, where people have to go outside for 15 minutes or
>>> so and collect data. Afterwards compare techniques, collected data and do a
>>> bit of mapping. Perhaps discuss a bit about usefulness, special maps, ...
>>>
>>>
>>>
>>> m.
>>>
>>>
>>>
>>> On Tue, Jan 8, 2019 at 1:46 PM Ben Abelshausen <
>>> ben.abelshau...@gmail.com> wrote:
>>>
>>> Hi everyone!
>>>
>>>
>>>
>>> In a few months we have Open Belgium again (yay!) and as usual we will
>>> have talks about OSM (Belgium).  We invite everyone to submit a talk,
>>> **anything** related to open-(something) is fine, that means openstreetmap
>>> too! ;-) We will also organize a community day during the weekend this
>>> year, more news about that later, so even if you can't make it on the 4th
>>> of march we urge you to submit talks/workshops anyway. We can move them to
>>> the community day later.
>>>
>>>
>>>
>>> We will probably also have a booth with OSM Belgium and usually have a
>>> lot of fun so don't miss it! If you want to attend but find the entry
>>> tickets too expense get in touch with me,

Re: [OSM-talk-be] Fwd: Open Belgium 2019: Call for Speakers + Early Bird Tickets!

[Marc Gemis]

I'm a bit confused about

- Open Belgium (on March 4)
and
- We will also organize a community day during the weekend this year

which weekend is that ? Which community (OpenBelgium or OSM or both) ?

I was also thinking (for a OSM public) -- at least I would be interested to
participate in such a workshop/presentation to learn more.

- Improve your armchair mapping with Mapillary and OpenStreetCam
  Explain the 2 project, techniques to use them in iD or JOSM, filter
images on "topic", ...
- Wikidata (and Wikipedia and Commons) for mappers.
What is Wikidata, how can you edit, how can you put data in OSM, potential
ideas for using a joined DB.


m.


On Wed, Jan 9, 2019 at 5:18 PM Jonathan Beliën  wrote:

> That’s a really awesome idea indeed !
> Thanks Marc !
>
>
>
> I’ll see if we can make that happen during OpenBelgium Community Day ! \o/
>
>
>
> Jonathan Beliën
> SPRL GEO-6 <https://geo6.be/>
>
>
>
> *De :* Santens Seppe 
> *Envoyé :* mercredi 9 janvier 2019 09:27
> *À :* OpenStreetMap Belgium 
> *Objet :* Re: [OSM-talk-be] Fwd: Open Belgium 2019: Call for Speakers +
> Early Bird Tickets!
>
>
>
> Cool idea, Marc!
>
>
>
> *Van:* Marc Gemis [mailto:marc.ge...@gmail.com]
> *Verzonden:* dinsdag 8 januari 2019 20:32
> *Aan:* OpenStreetMap Belgium
> *Onderwerp:* Re: [OSM-talk-be] Fwd: Open Belgium 2019: Call for Speakers
> + Early Bird Tickets!
>
>
>
> I cannot make it to Open Belgium, but I have been thinking about a
> "walking meetup" for some time now. So instead of sitting in a pub, doing a
> walk and talk about OSM and survey techniques and apply them.
>
> Taking that idea, on a community day, it could be a workshop about
> surveying techniques, JOSM tips, micromapping, that kind of stuff. It would
> be an hand-on workshop, where people have to go outside for 15 minutes or
> so and collect data. Afterwards compare techniques, collected data and do a
> bit of mapping. Perhaps discuss a bit about usefulness, special maps, ...
>
>
>
> m.
>
>
>
> On Tue, Jan 8, 2019 at 1:46 PM Ben Abelshausen 
> wrote:
>
> Hi everyone!
>
>
>
> In a few months we have Open Belgium again (yay!) and as usual we will
> have talks about OSM (Belgium).  We invite everyone to submit a talk,
> **anything** related to open-(something) is fine, that means openstreetmap
> too! ;-) We will also organize a community day during the weekend this
> year, more news about that later, so even if you can't make it on the 4th
> of march we urge you to submit talks/workshops anyway. We can move them to
> the community day later.
>
>
>
> We will probably also have a booth with OSM Belgium and usually have a lot
> of fun so don't miss it! If you want to attend but find the entry tickets
> too expense get in touch with me, the community day will be free (to be
> announced later).
>
>
>
> All details here:
>
>
>
> -- Forwarded message -
> From: *Astrid - Open Knowledge Belgium* 
> Date: Tue, Jan 8, 2019 at 10:17 AM
> Subject: Open Belgium 2019: Call for Speakers + Early Bird Tickets!
> To: 
>
>
>
> A must-attend conference to discuss the state of and current trends around
> Open Knowledge and Open Data!
>
> Open Belgium 2019 - 4 March in Brussels
> Open Knowledge and Open Data in Belgium
>
>
>
> View this email in your browser
> <https://mailchi.mp/d884372f2d2a/open-belgium-2019-call-for-speakers-early-bird-tickets?e=17370c2173>
>
> [image: Image supprimée par l'expéditeur.]
> <https://openbelgium.us8.list-manage.com/track/click?u=16c22b5f724fd6ef8c78c79fc&id=a9315be566&e=17370c2173>
>
>
> Let's talk Open Knowledge and Open Data!
> Ready for Open Belgium 2019?
>
>
> The Belgian open knowledge and open data landscape is changing at a fast
> pace. In order to stay up-to-date and to share insights with *300+ fellow
> open enthusiasts,* we would like to invite you to join us at the annual 
> *community-driven
> Open Belgium 2019
> <https://openbelgium.us8.list-manage.com/track/click?u=16c22b5f724fd6ef8c78c79fc&id=e72573f541&e=17370c2173>*
> conference on *4 March in Brussels*.
>
> Since you participated in previous editions of Open Belgium, you know
> exactly what to expect: inspirational high-level keynote speakers, engaging
> panel discussions, hands-on and minds-on workshops as well as an
> interactive exhibition space.
>
>
>
> Get your *Early Bird ticket* *now* and *save more than 30%!*
>
>
>
> *GET YOUR TICKET*
> <https://openbelgium.us8.list-manage.com/track/click?u=16c22b5f724fd6ef8c78c79fc&id=94d0ca47cc&e=17370c2173>
>
>
>
> *When?*
>
> *Mond

Re: [OSM-talk-be] Fwd: Open Belgium 2019: Call for Speakers + Early Bird Tickets!

[Marc Gemis]

I cannot make it to Open Belgium, but I have been thinking about a "walking
meetup" for some time now. So instead of sitting in a pub, doing a walk and
talk about OSM and survey techniques and apply them.

Taking that idea, on a community day, it could be a workshop about
surveying techniques, JOSM tips, micromapping, that kind of stuff. It would
be an hand-on workshop, where people have to go outside for 15 minutes or
so and collect data. Afterwards compare techniques, collected data and do a
bit of mapping. Perhaps discuss a bit about usefulness, special maps, ...

m.

On Tue, Jan 8, 2019 at 1:46 PM Ben Abelshausen 
wrote:

> Hi everyone!
>
> In a few months we have Open Belgium again (yay!) and as usual we will
> have talks about OSM (Belgium).  We invite everyone to submit a talk,
> **anything** related to open-(something) is fine, that means openstreetmap
> too! ;-) We will also organize a community day during the weekend this
> year, more news about that later, so even if you can't make it on the 4th
> of march we urge you to submit talks/workshops anyway. We can move them to
> the community day later.
>
> We will probably also have a booth with OSM Belgium and usually have a lot
> of fun so don't miss it! If you want to attend but find the entry tickets
> too expense get in touch with me, the community day will be free (to be
> announced later).
>
> All details here:
>
> -- Forwarded message -
> From: Astrid - Open Knowledge Belgium 
> Date: Tue, Jan 8, 2019 at 10:17 AM
> Subject: Open Belgium 2019: Call for Speakers + Early Bird Tickets!
> To: 
>
>
> A must-attend conference to discuss the state of and current trends around
> Open Knowledge and Open Data!
>
> Open Belgium 2019 - 4 March in Brussels
> Open Knowledge and Open Data in Belgium
> View this email in your browser
> 
>
> 
> Let's talk Open Knowledge and Open Data!
> Ready for Open Belgium 2019?
>
>
> The Belgian open knowledge and open data landscape is changing at a fast
> pace. In order to stay up-to-date and to share insights with *300+ fellow
> open enthusiasts,* we would like to invite you to join us at the annual 
> *community-driven
> Open Belgium 2019
> *
> conference on *4 March in Brussels*.
>
> Since you participated in previous editions of Open Belgium, you know
> exactly what to expect: inspirational high-level keynote speakers,
> engaging panel discussions, hands-on and minds-on workshops as well as an
> interactive exhibition space.
> Get your *Early Bird ticket* *now* and *save more than 30%!*
> GET YOUR TICKET
> 
>
> *When?*
> *Monday 4 March, 08:30-19:00*
> Full programme available soon
> *Where?*
> *Herman Teirlinck Building*
> Avenue du Port 88, 1000 Brussels
>
> 
> Link to Call for Speakers: http://2019.openbelgium.be/speakers
> 
>
> We are looking forward to seeing you at Open Belgium 2019!
>
> The Open Belgium team
>
>
> 
>
> 
>
> 
>
> 
> *Copyright © 2019 Open Knowledge Belgium, All rights reserved.*
> You are receiving this email because you attended Open Belgium in the past.
>
> *Our mailing address is:*
> Open Knowledge Belgium
> Kantersteen 12
> Brussels 1000
> Belgium
>
> Add us to your address book
> 
>
>
> Want to change how you receive these emails?
> You can update your preferences
> 
> or unsubscribe from this list
> 
> .
>
> [image: Email Marketing Powered by Mailchimp]
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> http

Re: [OSM-talk-be] Lijst van dorpen/gemeenten/steden naargelang grootte/belang

[Marc Gemis]

Voor mij lijkt Joost's vraag relevant aangezien Brussel misschien wel
een grote stad is naar Belgische normen, maar klein is in vergelijking
met Londen, Parijs of Madrid.

Verder is een plaats met 5000 inwoners misschien niet relevant in
Vlaanderen, maar in een gebied met lage bevolkingsdichtheid (Ik denk
bv. aan Zweden of Wales) wel. Dit is een probleem dat ze bij de
default kaartstijl op osm.org ook nog niet hebben kunnen oplossen.

m.

On Wed, Dec 26, 2018 at 6:31 AM Karel Adams  wrote:
>
> Europa.
>
> Maar wat is daarvan de relevantie?
>
> KA
>
> On 25/12/2018 21:52, joost schouppe wrote:
>
> Wat is de scope van je project? Vlaanderen, België, de wereld?
>
> Op ma 24 dec. 2018 11:52 schreef Karel Adams >
>> (ik denk dat ik dit punt reeds eerder aankaartte, maar heb nog steeds
>> geen oplossing, het blijft dus een probleem)
>>
>> Voor een eigen "moving-map" applicatie (waarover verder geen discussie
>> aub, want daarover gaat het niet) wil ik graag een lijst van
>> steden/dorpen/gemeenten vanuit openstreetmap, mèt indicatie van
>> omvang/belang/grootte.
>>
>> Het idee is dat ik een buitengemeente zoals (om maar iets te zeggen)
>> Wakkerzeel niet wil weergeven als ik mijn eigen dorp van Haacht weergeef
>> in een omgeving van 100 kilometer, maar wel in een omgeving van 10
>> kilometer.
>>
>> Maar hoe krijg ik uit OSM een indicatie van de grootte/belang van een
>> "localiteit"? "Aantal inwoners" gaat een eind de richting uit, maar is
>> lang niet overal ingevuld. "admin_level" lijkt veelbelovend, maar geeft
>> problemen met grotere steden, die enerzijds gemapt zijn als node maar
>> dan zonder admin_level, en anderszijds als "boundary", veelal een
>> "relation". En inderdaad lijkt die "admin_level" bedoeld te zijn om de
>> grenzen af te bakenen, niet om de gemeente te categoriseren.
>>
>> Kortom, wat ik wil bereiken is een lijstje zoals hieronder (met telkens
>> ook lengtegraad en breedtegraad erbij, maar dat haal ik wel uit
>> Overpass, die kan ik tegenwoordig query'en met mijn ogen dicht :) ), hoe
>> kom ik daaraan?
>>
>> Mechelengrote stad
>>
>> Leuven grote stad
>>
>> Lierminder grote stad
>>
>> Aarschotminder grote stad
>>
>> Haachtgemeente
>>
>> Wakkerzeeldeelgemeente
>>
>> Brusselzeer grote stad
>>
>> Antwerpenzeer grote stad, mét parking :)
>>
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Lijst van dorpen/gemeenten/steden naargelang grootte/belang

[Marc Gemis]

Hallo Karel,

inderdaad, OSM heeft niet echt tags om de grootte te bepalen. Zoals je
reeds aangaf is er de population tag, Er is ook de place-tag. Ik dacht
dat deze 2 tags in combinatie met capital, gebruikt worden door bv. de
standard kaartstijl op openstreetmap.org om te bepalen op welk zoom
level een stad/gemeente moet getekend worden.

Een andere manier is de grootte van het gebied afgelijnd door de
administratieve grenzen te nemen. Deze grenzen zijn niet altijd
gemapped. In Vlaanderen zijn alle admin level 8 (steden/gemeenten) wel
in kaart gebracht, evenals admin level 9 (de deelgemeenten). Dit hoeft
niet het geval te zijn in andere landen/streken.

m.

On Mon, Dec 24, 2018 at 5:52 PM Karel Adams  wrote:
>
> (ik denk dat ik dit punt reeds eerder aankaartte, maar heb nog steeds
> geen oplossing, het blijft dus een probleem)
>
> Voor een eigen "moving-map" applicatie (waarover verder geen discussie
> aub, want daarover gaat het niet) wil ik graag een lijst van
> steden/dorpen/gemeenten vanuit openstreetmap, mèt indicatie van
> omvang/belang/grootte.
>
> Het idee is dat ik een buitengemeente zoals (om maar iets te zeggen)
> Wakkerzeel niet wil weergeven als ik mijn eigen dorp van Haacht weergeef
> in een omgeving van 100 kilometer, maar wel in een omgeving van 10
> kilometer.
>
> Maar hoe krijg ik uit OSM een indicatie van de grootte/belang van een
> "localiteit"? "Aantal inwoners" gaat een eind de richting uit, maar is
> lang niet overal ingevuld. "admin_level" lijkt veelbelovend, maar geeft
> problemen met grotere steden, die enerzijds gemapt zijn als node maar
> dan zonder admin_level, en anderszijds als "boundary", veelal een
> "relation". En inderdaad lijkt die "admin_level" bedoeld te zijn om de
> grenzen af te bakenen, niet om de gemeente te categoriseren.
>
> Kortom, wat ik wil bereiken is een lijstje zoals hieronder (met telkens
> ook lengtegraad en breedtegraad erbij, maar dat haal ik wel uit
> Overpass, die kan ik tegenwoordig query'en met mijn ogen dicht :) ), hoe
> kom ik daaraan?
>
> Mechelengrote stad
>
> Leuven grote stad
>
> Lierminder grote stad
>
> Aarschotminder grote stad
>
> Haachtgemeente
>
> Wakkerzeeldeelgemeente
>
> Brusselzeer grote stad
>
> Antwerpenzeer grote stad, mét parking :)
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Update Slow Roads conventions Belgium

[Marc Gemis]

Sometimes references contain language specific information. Some
substations have CAB 12 as reference. I assume CAB refers somehow to
Cabine, which would not have been there if we would live e.g. in
Russia.
The same with the 'E' / 'A' / 'N' used to indicate road nummers.

We never put the name of the street in name:nl for other roads, why
would we do that for vicinal roads ?

Another example that I want to map is:
https://xian.smugmug.com/OSM/OSM-2018/2018-09-22-Londerzeel/i-SndFGmx/A

As a simple surveyor that does not want to look at ancient road
atlasses I thought of mapping this just as

name=Pluimennest
alt_name=Merchtemscheweg
vicinal_ref=Voetweg 25

If there is another simple method to map "Voetweg" and "25" we could
use that as well. But I assume that the signs sometimes do not
correspond to what the "Atlas" has.

Note that Voetweg/Buurtweg is not always written as such. In Rumst
they use VW and BW followed by the number. This is much closer to the
usage of e.g. A12 (which we also do not write as Autoweg 12, nor as 12
with and extra designation or road type tag).

m.

On Sat, Dec 15, 2018 at 3:20 PM Karel Adams  wrote:
>
> But - for as little as I am acquainted with this specific matter - I should 
> think language-related terms should never occur in a reference? I would 
> expect and indeed welcome them in a name tag, probably language-specific like 
> name:nl
>
> KA
>
> On 15/12/2018 14:13, Steven Clays wrote:
>
> Indeed, that's why. Actually, it is a good way to deal with the sometimes 
> blurry denominations on the signposts.
>
> Op za 15 dec. 2018 om 14:59 schreef Marc Gemis :
>>
>> I suggested that, as I think it is an part of the ref. We do map "E19"
>> as well, not just 19.
>> I want to be able te reconstruct the sign as I see it during a survey.
>> On Sat, Dec 15, 2018 at 2:47 PM Ben Laenen  wrote:
>> >
>> > One question I have: why are the words "chemin", "sentier", "voetweg" etc. 
>> > part of the vicinal_ref tag? Better just leave the number in there, the 
>> > type of road is in the vicinal_type tag.
>> >
>> > Ben
>> >
>> > On Sat, 15 Dec 2018, 12:33 Steven Clays > >>
>> >> Hello,
>> >>
>> >> I made a slight overhaul of the slow roads Belgium page, based on the 
>> >> discussion of Friday December 14th. A new tagging scheme is also 
>> >> proposed, seperating vicinal_ref and oficial_vicinal_ref. Links are 
>> >> restored and some pictures added. Comments and improvements welcome. 
>> >> https://wiki.openstreetmap.org/w/index.php?title=WikiProject_Belgium/Conventions/Slowroads&wteswitched=1#Trage_wegen_Inventory
>> >> ___
>> >> Talk-be mailing list
>> >> Talk-be@openstreetmap.org
>> >> https://lists.openstreetmap.org/listinfo/talk-be
>> >
>> > ___
>> > Talk-be mailing list
>> > Talk-be@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-be
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Update Slow Roads conventions Belgium

[Marc Gemis]

I don't want to reconstuct the map from 1800, I want to map what I see
on the sign.
If I see a sign like
https://xian.smugmug.com/OSM/OSM-2018/2018-10-07-Opdorp-Lippelobos/i-sFgCzRj,
I want to somehow map "Lippelooweg / Buurtweg 57" and "Buurtweg 58",
regardless of what a map from 1800 says.

m.
On Sat, Dec 15, 2018 at 3:17 PM Ben Laenen  wrote:
>
>
>
> On Sat, 15 Dec 2018, 14:59 Marc Gemis >
>> I suggested that, as I think it is an part of the ref. We do map "E19"
>> as well, not just 19.
>> I want to be able te reconstruct the sign as I see it during a survey.
>
>
>
> Yeah but those words aren't very consistent in usage, do you take the French 
> words for Flemish roads because the Atlas was made in French for that 
> municipality? In the end there are only two types, a path and a road, and 
> there's no difference in a path being a sentier, pad, voetpad or voetweg on 
> one map from the 1800s.
>
> Also, if you want what's on the map, you'd need to have "Sentier n° 117" as 
> well for example.
>
> Ben
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Update Slow Roads conventions Belgium

[Marc Gemis]

I suggested that, as I think it is an part of the ref. We do map "E19"
as well, not just 19.
I want to be able te reconstruct the sign as I see it during a survey.
On Sat, Dec 15, 2018 at 2:47 PM Ben Laenen  wrote:
>
> One question I have: why are the words "chemin", "sentier", "voetweg" etc. 
> part of the vicinal_ref tag? Better just leave the number in there, the type 
> of road is in the vicinal_type tag.
>
> Ben
>
> On Sat, 15 Dec 2018, 12:33 Steven Clays >
>> Hello,
>>
>> I made a slight overhaul of the slow roads Belgium page, based on the 
>> discussion of Friday December 14th. A new tagging scheme is also proposed, 
>> seperating vicinal_ref and oficial_vicinal_ref. Links are restored and some 
>> pictures added. Comments and improvements welcome. 
>> https://wiki.openstreetmap.org/w/index.php?title=WikiProject_Belgium/Conventions/Slowroads&wteswitched=1#Trage_wegen_Inventory
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] identifier in ref:xOperatorx=y0yyyy to url=http://mijnlijn.be/y0yyyy

[Marc Gemis]

I would not drop the ref. The ref is visible on the signs, so it is a
"real thing". I have no problem that people add the URL as well. The
same is done for heritage sites. There is both a ref
(refLOnroerendErfgoed and a heritage:website.)

m.
On Sun, Nov 18, 2018 at 10:52 AM Jo  wrote:
>
> Our bus stops in Flanders have unique identifiers visible to the public on 
> the flags of the stop poles.
>
> I started by entering those in the ref tag, then later decided to use 
> ref:De_Lijn=y0, as some of those stops are served by other operators as 
> well.
>
> For several years now itt's possible to obtain real-time information about 
> the buses on a url+identifier, so I want to add that to those stops. As i 
> don't like to duplicate information I'd prefer to drop the ref:De_Lijn though.
>
> So all of those stops would have:
> url=http://mijnlijn.be/303079(<- you can test this, the url is 
> expanded/translated to a url on www.delijn.be)
>
> For the conversion, I'd like to launch a Belgian "Project of the month", so 
> the position of the stops can be verified once more by locals, but also 
> shelters and bus_bays can be added and if cycle ways split off to go around 
> those bus bays, that detail can be added as well.
>
> I know that that is what we have been doing for the past 5+ years, but now it 
> would get some more dedicated focus.
>
> For several years I thought having the identifier n a dedicated ref:X tag and 
> then telling everyone about how to turn it into such a url was the way to 
> go,. That doesn't actually work though. Nobody knows how to get from the 
> identifer to the url. Giving potential passengers a url they can simply click 
> through on, seems to be the better way of doing this for this use case.
>
> Polyglot
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] OSM.be versus OpenStreetMap.be

[Marc Gemis]

.nl .ie .de. fr .be .jp .us  --> no map, or map as background.
.ch .org --> map
.it -> just some text + link to wiki


On Mon, Nov 12, 2018 at 8:21 AM OSMDoudou
<19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
>
> It’s fine as long as it’s consistent and predictable for the user.
>
> If a regional domain shows a map and another the chapter info, it can be 
> confusing.
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] OSM.be versus OpenStreetMap.be

[Marc Gemis]

But nor openstreetmap.fr nor openstreetmap.de show "the" map on the
landing page. They focus on community and possibilities of the
database, not just on a single representation of the map data.

m.


On Sun, Nov 11, 2018 at 10:45 PM OSMDoudou
<19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
>
> Second thoughts...
>
> When you visit a .com website, which also has an affiliated regional website, 
> like .be, you expect to find the same stuff but in the local language and 
> with local products.
>
> By the logic above, openstreetmap.be should show the map centered on Belgium.
>
> In the case of openstreetmap.org and openstreetmap.be, they would be totally 
> different.
>
> My 2ç.
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Where can I geocode 3 mln addresses?

[Marc Gemis]

Keep in mind that the address database of OSM is far from complete.
Brussels is probably OK (Urbis DB was imported), for Flanders and
Wallonia, it depends on the mappers. In Flanders, an import/merge
operation is planned based on GRB. At this moment some mappers are
still adding addresses based on CRAB.
In Wallonia, it is still "manual" work. Go out and survey for addresses,

m.
On Fri, Nov 9, 2018 at 10:31 AM Alexander Mikhailian
 wrote:
>
> On Fri, Nov 09, 2018 at 04:48:36AM +0400, mars.vard wrote:
>
> > Can you tell more about the visualisations you want to achieve?
>
> I like the recent population density map by Matt Daniels [1] and want to
> copy cat it for Belgium using KBO/BCE data.
>
> Anyway, it looks like I already found the answer. The only affordable
> way to do geomapping on 3mln addresses is with a local copy of
> Nominatim.
>
>
> [1] 
> https://blog.mapbox.com/3d-mapping-global-population-density-how-i-built-it-141785c91107
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Note tells OSM fails

[Marc Gemis]

thanks, so we do not have to change that.
On Wed, Sep 5, 2018 at 11:12 AM Gerard Vanderveken  wrote:
>
> It's the Metro and the MIVB/STIB uses Crainhem as official name in 
> translation for Kraainem.
> It is located in Brussels, so name rules of Kraainem (NL first), which is in 
> the Flemish Region don't apply.
>
> Regards,
> Gerard
>
> Marc Gemis wrote:
>
> What about the railway station
> https://www.openstreetmap.org/node/250310431 ? Still uses Crainhem. Is
> that the official name used by NMBS ?
> On Wed, Sep 5, 2018 at 9:40 AM Lionel Giard  wrote:
>
>
> The official french name is "Kraainem" too, while Crainhem is an alternate 
> spelling for french (but i had never seen it before). Maybe we should change 
> the tag and put it like that "name:fr=Kraainem" and "alt_name:fr= Crainhem" ?
>
> Le mar. 4 sept. 2018 à 20:43, Marc Gemis  a écrit :
>
>
> I replied with the same names as person used in the original note.
> Kraainem is named Kraainem in the name and name:nl fields.
>
> It is possible that Nominatim returns the name:fr field in case you
> have your browser configured to prefer French above Dutch.
>
> m.
> On Tue, Sep 4, 2018 at 7:21 PM Karel Adams  wrote:
>
>
> In the margin and without wishing to enter politics, allow me to insist
> we should name the village by its primary and original name "Kraainem".
>
>
> On 04/09/18 09:39, Marc Gemis wrote:
>
>
> Here is the answer I gave on the note:
>
> As you can see on the map, the boundary between Woluwe-Saint-Pierre
> and Crainhem runs slighty left of the Rue Longue.
>
> Since the current implementation of Nominatim (the software that looks
> up the addresses), always looks at the street and never at the POIs,
> there is no way to solve this with data.
>
> AFAIK, they are working on a solution for this, but there is no
> timeframe for a solution
>
> m.
> On Tue, Sep 4, 2018 at 9:38 AM Jakka  wrote:
>
>
> Hi,
>
> Who can answer and close this note.
> Building is located in Woluwe-Saint-Pierre but access highway is in
> Crainhem I think...
> https://www.openstreetmap.org/note/1477650#map=19/50.84217/4.46717
> https://nominatim.openstreetmap.org/details.php?place_id=84536059
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Note tells OSM fails

[Marc Gemis]

What about the railway station
https://www.openstreetmap.org/node/250310431 ? Still uses Crainhem. Is
that the official name used by NMBS ?
On Wed, Sep 5, 2018 at 9:40 AM Lionel Giard  wrote:
>
> The official french name is "Kraainem" too, while Crainhem is an alternate 
> spelling for french (but i had never seen it before). Maybe we should change 
> the tag and put it like that "name:fr=Kraainem" and "alt_name:fr= Crainhem" ?
>
> Le mar. 4 sept. 2018 à 20:43, Marc Gemis  a écrit :
>>
>> I replied with the same names as person used in the original note.
>> Kraainem is named Kraainem in the name and name:nl fields.
>>
>> It is possible that Nominatim returns the name:fr field in case you
>> have your browser configured to prefer French above Dutch.
>>
>> m.
>> On Tue, Sep 4, 2018 at 7:21 PM Karel Adams  wrote:
>> >
>> > In the margin and without wishing to enter politics, allow me to insist
>> > we should name the village by its primary and original name "Kraainem".
>> >
>> >
>> > On 04/09/18 09:39, Marc Gemis wrote:
>> > > Here is the answer I gave on the note:
>> > >
>> > > As you can see on the map, the boundary between Woluwe-Saint-Pierre
>> > > and Crainhem runs slighty left of the Rue Longue.
>> > >
>> > > Since the current implementation of Nominatim (the software that looks
>> > > up the addresses), always looks at the street and never at the POIs,
>> > > there is no way to solve this with data.
>> > >
>> > > AFAIK, they are working on a solution for this, but there is no
>> > > timeframe for a solution
>> > >
>> > > m.
>> > > On Tue, Sep 4, 2018 at 9:38 AM Jakka  wrote:
>> > >> Hi,
>> > >>
>> > >> Who can answer and close this note.
>> > >> Building is located in Woluwe-Saint-Pierre but access highway is in
>> > >> Crainhem I think...
>> > >> https://www.openstreetmap.org/note/1477650#map=19/50.84217/4.46717
>> > >> https://nominatim.openstreetmap.org/details.php?place_id=84536059
>> > >>
>> > >>
>> > >> ___
>> > >> Talk-be mailing list
>> > >> Talk-be@openstreetmap.org
>> > >> https://lists.openstreetmap.org/listinfo/talk-be
>> > > ___
>> > > Talk-be mailing list
>> > > Talk-be@openstreetmap.org
>> > > https://lists.openstreetmap.org/listinfo/talk-be
>> >
>> >
>> > ___
>> > Talk-be mailing list
>> > Talk-be@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-be
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Note tells OSM fails

[Marc Gemis]

I replied with the same names as person used in the original note.
Kraainem is named Kraainem in the name and name:nl fields.

It is possible that Nominatim returns the name:fr field in case you
have your browser configured to prefer French above Dutch.

m.
On Tue, Sep 4, 2018 at 7:21 PM Karel Adams  wrote:
>
> In the margin and without wishing to enter politics, allow me to insist
> we should name the village by its primary and original name "Kraainem".
>
>
> On 04/09/18 09:39, Marc Gemis wrote:
> > Here is the answer I gave on the note:
> >
> > As you can see on the map, the boundary between Woluwe-Saint-Pierre
> > and Crainhem runs slighty left of the Rue Longue.
> >
> > Since the current implementation of Nominatim (the software that looks
> > up the addresses), always looks at the street and never at the POIs,
> > there is no way to solve this with data.
> >
> > AFAIK, they are working on a solution for this, but there is no
> > timeframe for a solution
> >
> > m.
> > On Tue, Sep 4, 2018 at 9:38 AM Jakka  wrote:
> >> Hi,
> >>
> >> Who can answer and close this note.
> >> Building is located in Woluwe-Saint-Pierre but access highway is in
> >> Crainhem I think...
> >> https://www.openstreetmap.org/note/1477650#map=19/50.84217/4.46717
> >> https://nominatim.openstreetmap.org/details.php?place_id=84536059
> >>
> >>
> >> ___
> >> Talk-be mailing list
> >> Talk-be@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-be
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Note tells OSM fails

[Marc Gemis]

Here is the answer I gave on the note:

As you can see on the map, the boundary between Woluwe-Saint-Pierre
and Crainhem runs slighty left of the Rue Longue.

Since the current implementation of Nominatim (the software that looks
up the addresses), always looks at the street and never at the POIs,
there is no way to solve this with data.

AFAIK, they are working on a solution for this, but there is no
timeframe for a solution

m.
On Tue, Sep 4, 2018 at 9:38 AM Jakka  wrote:
>
> Hi,
>
> Who can answer and close this note.
> Building is located in Woluwe-Saint-Pierre but access highway is in
> Crainhem I think...
> https://www.openstreetmap.org/note/1477650#map=19/50.84217/4.46717
> https://nominatim.openstreetmap.org/details.php?place_id=84536059
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] int_ref, ref spelling, no space between letter and number....

[Marc Gemis]

When you search for "blank" on Wikipedia, you will find some
disambiguation pages (a.o https://en.wikipedia.org/wiki/Blank_space),
and finally end up on :
https://en.wikipedia.org/wiki/Space_(punctuation)
So space is correct.

m.

p.s. Do we need to ask people not to write in Dutch whenever they
violate the dt-rule ? :-)
p.p.s Do you read the Dutch forum ? I sometimes have to read certain
posts 3 or 4 times to understand the "Dutch" that is used there. So I
do not bother the occasional typo in English.
On Sat, Aug 11, 2018 at 3:49 PM Karel Adams  wrote:
>
> Thanks, Jo, you are looking on from a little distance, that is always helpful 
> to get consensus...
>
> I agree with your "the key to create such a blank is commonly known as the 
> space bar" - which only confirms how subtle the English language really is. 
> And that is precisely what makes me contest the "rule" cited by @Ruben 
> (he/she is right in the citation, but I defy the rule) "on this list the 
> accepted standard is to use English" - I never liked that rule, mostly for 
> this reason. There's all too many people who post (to some degree) gibberish, 
> in the firm belief they have good English.
>
> And to come back to @Ruben's reply "no-one would have failed to understand 
> what we meant": try taking this conversation though some www translation tool 
> to an exotic language, say Japanese or Swahili or Latin or Basque, than back 
> to English. Without having checked, I dare to bet that somewhere in the 
> process the "space" was converted to something astronautical. So yes, I am 
> sure many people might get confused. Or in other words, what's the added 
> value of posting in a language that is NOT native to this Belgian country? 
> Except of course to oblige those few who prefer learning foreign languages 
> over learning their own.
>
> Karel (admittedly touchy on matters of language and local culture)
>
>
> On 11/08/18 13:31, Jo wrote:
>
> Karel, you are probably right, but the key to create such a blank is commonly 
> known as the space bar.
>
> I would also remove the 'empty character' (Leerzeichen) here in Belgium.
>
> In France it's consistently with a space, I guess they find it like that on 
> their signage.
>
> Jo
>
> Op za 11 aug. 2018 om 15:11 schreef Karel Adams :
>>
>> Excuse me for being pecky on language - for this once I feel free
>> because language is (more or less) the subject matter anyway.
>>
>> Where @jakka writes "space", and @ruben neatly follows suit, I think the
>> actual meaning is "blank".
>>
>> nl "spatie" => en "blank"
>>
>> en "space" => nl "ruimte"
>>
>> Not wanting to "score" any personal hits, just for the common good:
>> allow me to recommend that English should only be used by those who
>> master that subtle language really well. There is no reason for not
>> posting in one's native language, on a list of regional importance such
>> as this.
>>
>> Groeten :)
>>
>> Karel
>>
>>
>> On 11/08/18 12:38, Ruben wrote:
>> > Hi Frank,
>> >
>> > On Fri, 10 Aug 2018 21:06:54 +0200, Jakka  wrote:
>> >> Where can I see and read what is the correct spelling of the E and other 
>> >> road network like A? Is there a space between the letter and number?
>> >> The wiki pages 
>> >> https://wiki.openstreetmap.org/wiki/WikiProject_Europe/E-road_network and 
>> >> https://en.wikipedia.org/wiki/International_E-road_network are not clear 
>> >> about that...
>> >> See the mapillary https://www.mapillary.com/map/im/vEtPrDgYQ9nVD2kfehABQg 
>> >> example: there are no spaces so should we adapt all those tags?
>> > I believe our local refs are without space (so "A17", "R0", "N540"). Our 
>> > signposting for international refs doesn't use a space either (E40), or 
>> > sometimes a 'thin space' (E 40). I've never seen a full space (E 40).
>> > On their site[1], the Flemish Agency for Roads and Traffic (AWV) 
>> > consistently uses no space for both local and E refs. So I'd be inclined 
>> > to say it's without space.
>> >
>> >> I see that most of int_ref is with space and ref and nat_ref without? But 
>> >> not always...
>> > A few years ago, a French mapper came along and mechanically edited 
>> > int_refs in Belgium. I asked them to stop but their changes were never 
>> > fully reverted, so there are still int_refs with a space in Belgium.
>> > I think it would be safe to remove the spaces mechanically, as it would 
>> > actually be reverting an earlier unauthorized mechanical edit. What do you 
>> > think?
>> >
>> > [1] https://wegenenverkeer.be/
>> >
>> > Cheers,
>> > Ruben
>> >
>> > ___
>> > Talk-be mailing list
>> > Talk-be@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreet

Re: [OSM-talk-be] JOSM preset "Mapping in Belgium" updated (Santens Seppe)

[Marc Gemis]

is gebeurd.

Ik dacht dat ik dat een tijdje geleden al had aangepast, maar ik had
blijkbaar enkel de 2 andere tags vervangen door emergency=life_ring
On Tue, Aug 7, 2018 at 2:17 PM Philippe Casteleyn
 wrote:
>
> Ik zou
>
> 
>
> weg laten.
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

[OSM-talk-be] Mapper of the Month

[Marc Gemis]

In case you didn't know, we still publish mapper of the month
interviews every month :-)

This time: Lionel Giard (Belgium).

en: http://www.osm.be/2018/07/13/en-motm-lionel_giard.html
fr: http://www.osm.be/2018/07/13/fr-motm-lionel_giard.html
nl: http://www.osm.be/2018/07/13/nl-motm-lionel_giard.html

enjoy

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

Re: [OSM-talk-be] Mappen van spoorweginfrastructuur

[Marc Gemis]

dat is nochtans hoe het beschreven staat op de wiki :
https://wiki.openstreetmap.org/wiki/User:Eimai/Belgian_Roads#Paths
On Fri, Jun 29, 2018 at 6:33 PM Wouter Hamelinck
 wrote:
>
>
>> > Op zich is er geen reden om die weg te splitsen: die nodes met 
>> > barrier=block zouden moeten volstaan voor routing software. En naar mijn 
>> > mening wordt die weg geen 'path' door die blokken.
>>
>> "In mijnen tijd" werd in geen enkele router rekening gehouden met barriers 
>> op wegen, vandaar dat ik de neiging heb altijd de weg te splitsen, en ook de 
>> tags op de barrier vergeet (wat nu dus inderdaad problematisch is).
>>
>> Maar als er aan beide kanten van de overweg blokken staan, wordt het deel 
>> ertussen imo de facto wel een path, dus ik zou het hier toch nog steeds 
>> splitsen.
>
>
> Dit is zo een redenering die ik echt niet volg. Soms zie ik het nog extremer 
> doorgetrokken en wordt een weg als path of footway aangegeven omwille van een 
> bord C1 (rond met rode rand) dat de toegang beperkt. Voor mij blijft een weg 
> een weg, meestal highway=unclassified. Inderdaad de toegang verandert, maar 
> daar dient de access-tag voor en niet de highway-tag naar mijn mening.
>
> wouter
>
> --
> "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

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

Re: [OSM-talk-be] Mappen van spoorweginfrastructuur

[Marc Gemis]

Volgens Richard Fairhurst worden blockades voorgesteld door nodes nu
wel ondersteund door OSRM and Graphhopper, zie commentaar van
"Richard" op mijn antwoord bij
https://help.openstreetmap.org/questions/64292/do-you-add-a-gate-by-node-on-a-way-or-by-adding-a-point-by-itself

De wereld staat dus niet stil :-)

m.

On Fri, Jun 29, 2018 at 6:17 PM Ruben  wrote:
>
> On Wed, 27 Jun 2018 15:26:18 + (UTC), Stijn Rombauts 
>  wrote:
> > >> * de overweg is met grote plastic blokken afgesloten voor autoverkeer, 
> > >> >> al staan er geen overeenkomstige borden; fietsers en voetgangers 
> > >> kunnen
> > >> er nog wel langs, en doen dat ook. Geluidssignaal en knipperlichten zijn
> > >> ook actief ten gepasten tijde. Maar hoe mappen we dat?
> > >
> > >barrier=block op de baan ter hoogte van de blokken.
> > >De weg splitsen ter hoogte van de blokken, en op het stuk ertussen 
> > >highway=path foot=yes bicycle=yes moped=yes
> >
> > Dit is nagenoeg volledig fout...
> > De meeste 'barriers' hebben impliciet access=no [1]. Dus je moet expliciet 
> > aangeven wie er toch mag passeren: foot=yes, enz...
> > Op zich is er geen reden om die weg te splitsen: die nodes met 
> > barrier=block zouden moeten volstaan voor routing software. En naar mijn 
> > mening wordt die weg geen 'path' door die blokken.
>
> "In mijnen tijd" werd in geen enkele router rekening gehouden met barriers op 
> wegen, vandaar dat ik de neiging heb altijd de weg te splitsen, en ook de 
> tags op de barrier vergeet (wat nu dus inderdaad problematisch is).
>
> Maar als er aan beide kanten van de overweg blokken staan, wordt het deel 
> ertussen imo de facto wel een path, dus ik zou het hier toch nog steeds 
> splitsen.
>
> > Als je er toch een 'path' van wil maken: een highway=path heeft als default 
> > motor_vehicle=no [2]. Foot=yes en bicycle=yes toevoegen is compleet 
> > overbodig; moped=yes toevoegen is wel nodig.
>
> Goed. Ik kende die defaults niet echt.
>
> > Als je highway=residential behoudt, val je terug op de algemene regel dat 
> > highway=* impliceert access=yes. De elegantste manier om voetgangers, 
> > fietsers, brommertjes en waarschijnlijk ook ruiters toe te laten, is 
> > motor_vehicle=no, moped=yes.
> >
> > [1] https://wiki.openstreetmap.org/wiki/Barriers
> > [2] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Mappen van spoorweginfrastructuur

[Marc Gemis]

die tag is volgens mij enkele jaren geleden op deze mailing list besproken.
aangezien het zo goed als onmogelijk is om het archief te doorzoeken,
laat ik dat aan een ander over om die discussie terug te vinden. Omdat
er toen geen andere tags beschikbaar waren hebben we die tag
ingevoerd.

 Tagging evolueert over tijd, maar ik heb geen tijd om alle
"speciallekes" op te volgen. Dus alle hulp is welkom om  de BENELUX
preset aanpassen.aan de nieuwe consensus.

m.
On Sat, Jun 23, 2018 at 7:12 PM Ruben  wrote:
>
> Dag Karel
>
> On Sat, 23 Jun 2018 13:32:26 +, Karel Adams  wrote:
> > Op de locatie Noord 50.96277 Oost 4.62709 is er een overweg met
> > slagbomen. Deze is gemapt met twee nodes, een op elk spoor, met tag
> > railway=level_crossing.
> >
> > * het zou mij correcter lijken om maar één overweg te mappen ipv twee
>
> Bij een overweg krijgt elke node die de verkeersbaan met een spoor kruist, 
> een level_crossing-tag, en alle informatie wordt herhaald op elke node. Dat 
> is de status quo. Ik zie als alternatief een area tekenen rond heel de 
> overweg, of een node in het midden ervan, maar dat wordt niet gedaan. De 
> validators zullen daar ook over klagen.
>
> > * er is niet gemapt of het een bewaakte overweg is, ttz met slagbomen,
> > dan wel een onbewaakte met enkel licht- en geluidssignalen. Hoe te
> > verbeteren?
>
> Zie https://wiki.openstreetmap.org/wiki/Tag:railway%3Dlevel_crossing
>
> > * de overweg is met grote plastic blokken afgesloten voor autoverkeer,
> > al staan er geen overeenkomstige borden; fietsers en voetgangers kunnen
> > er nog wel langs, en doen dat ook. Geluidssignaal en knipperlichten zijn
> > ook actief ten gepasten tijde. Maar hoe mappen we dat?
>
> barrier=block op de baan ter hoogte van de blokken.
> De weg splitsen ter hoogte van de blokken, en op het stuk ertussen 
> highway=path foot=yes bicycle=yes moped=yes
>
> > * het zou mij ook gepast lijken om het nummer van de overweg te mappen,
> > hier is dat 21 zoals ik zag op bordjes langs het spoor.
>
> ref=* op elke node die je de tag railway=level_crossing gaf.
>
> ref is de tag voor allerlei identificatienummers, zoals die van 
> verlichtingspalen, elektriciteitskotjes, ATMs, spoorwegseinen, 
> spoorweglijnen, bushaltes, enzovoort.
>
> > Of mappen we
> > enkel "straat"-informatie, omdat we nu eenmaal niet "openrailmap" zijn?
>
> Dat zijn we wel: https://www.openrailwaymap.org/ (gebruikt enkel OSM-data)
>
> > * gelijkaardige vraag voor de seinen langsheen het spoor, we mappen wel
> > verkeerslichten voor auto's, waarom zouden we ook niet de
> > verkeerslichten van de treinen mappen?
>
> Er zijn veel verschillende soorten seinen, en dat verschilt dan ook nog eens 
> per land. Eimai is begonnen aan een schema voor de Belgische seinen ( 
> https://wiki.openstreetmap.org/wiki/User:Eimai/Railway ), maar het sluit niet 
> zo goed aan bij de internationale standaarden daarrond. In Duitsland staan ze 
> daar veel verder mee. Er zijn er daar ook al heel veel gemapt, in België nog 
> zo goed als geen.
>
> Ik map af en toe eens een sein, vooral in stations als ik toch aan het 
> wachten op de trein. Belgische seinen mappen is niet eenvoudig want de 
> soorten seinen herkennen is nogal lastig als leek. Ik heb het seinsysteem 
> bestudeerd en tekeningetjes gezet op Eimai's pagina om dat wat eenvoudiger te 
> maken. Maar ook ik zie nog steeds niet op zicht het verschil tussen een sein 
> dat het dubbel-geelaspect kan tonen en één dat dubbel geel, horizontaal 
> groen-geel en verticaal groen-geel kan tonen.
>
> Als je het seinstelsel niet diepgaand kent, zal je deze tags waarschijnlijk 
> niet kunnen gebruiken: managed, big_stop_sign_type, passing_at_danger, 
> big_signal_speed_sign, warning_signal_speed_sign en etcs_sign. Overige 
> informatie normaal gezien wel: type, ruleset, direction, position, regime, 
> down_gradient.
>
> > NB node 301223613 aan de volgende overweg (#20, dus :) ) geeft wel wat
> > meer info; is dit de correcte manier?
>
> level_crossing:category is niet gedocumenteerd en dus zinloos, dat zou ik 
> niet gebruiken. De rest van de tags zijn volgens mij gewoon uitgevonden. 
> Zeker niet als voorbeeld nemen. Ik heb een comment gelaten op de 
> wijzigingenset die ze introduceert.
>
>
> Groeten
> Ruben
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Mapping of motorways - use of int_ref tag on nodes?

[Marc Gemis]

int_ref only on way.
I think most motorways in Belgium where mapped correctly, before this change.

Perhaps a mistake of the user which selected ways and nodes before
adding/changing the int_ref ?
Feel free to reach out to the mapper that made the mistake.

regards

m.
On Fri, Jun 22, 2018 at 1:26 AM Yves bxl-forever
 wrote:
>
> Hello,
>
> I came across something fishy:
>
> node
>   [int_ref="E 411"]
>   (50.792806,4.417019,50.823614,4.481392);
> out;
>
>
> It seems that someone is routinely applying the "int_ref" tag on all 
> individual nodes of motorways.  This seems weird and it duplicates a lot of 
> information, because this is normally already there on the way.
>
> If that is not okay, I’ll try to get in touch with the mapper who did that.
> Is anyone familiar with how to map motorways properly?
>
> Thanks.
> Yves
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Nodes or areas to tag amenities

[Marc Gemis]

how does someone "improve" your mapping to add a separate area for
room=toilets ? nested room areas ? split it off ?

m.

On Wed, Apr 18, 2018 at 12:43 PM, Ubipo .  wrote:
> Regarding the housenumbers: street and number is as said probably not needed
> and better reserved for the actual building, although a specialised
> addr:addition=a could be useful for the rooms.
> Regarding room=restaurant, I think that tag is perfectly fine. It just
> indicates the restaurant in it's entirety, with dining room, kitchen etc.
>
> On Wed, Apr 18, 2018, 12:10 marc marc  wrote:
>>
>> for the addr : it look like strange that the room is in a building that
>> doesn't have the same addr:housenumber as the building.
>>
>> for multiple floors poi, you can draw all room with level=* tag
>> or as a first step only use indoor=yes for the whole area
>>
>> room=restaurant look like also strange for me.
>> a restaurant is several room=* item : kitchen, dining room, toilets,
>> cloakroom
>> so what's a room=restaurant ? it can not be the same as the area used
>> for amenity=restaurant. maybe it should be the area for the dining room.
>> the wiki advice to put both tag to the same polygon look like wrong.
>>
>>
>> Le 18. 04. 18 à 11:56, Marc Gemis a écrit :
>> > o, I forgot, what about a restaurant that occupies multiple floors ?
>> >
>> >
>> >
>> > On Wed, Apr 18, 2018 at 11:55 AM, Marc Gemis 
>> > wrote:
>> >> The idea of using indoor mapping is good, and it's probably the future
>> >> to solve all the problems you mention. (we had a similar discussion
>> >> last Friday on the Riot channel)
>> >>
>> >> Some remarks:
>> >>
>> >> - does it make sense for a "room" to have an house number and a street
>> >> ? I would expect those on the building, and floor or level or so on
>> >> the room.
>> >> - I'm not familiar enough with the simple  indoor tagging, but I would
>> >> expect that a restaurant exists of multiple rooms (dining, toilets,
>> >> kitchen) not just one.
>> >> - On the Riot channel the entrance to the restaurant was also seen as
>> >> important.
>> >>
>> >> m
>> >>
>> >> On Wed, Apr 18, 2018 at 10:06 AM, Ubipo . 
>> >> wrote:
>> >>> Everyone,
>> >>>
>> >>> A long standing question for osm mapping in cities is wether to tag
>> >>> amenities in multi-purpose buildings as:
>> >>> - a separate node inside the building's way
>> >>> - the building itself, using both building=house and amenity=* (only
>> >>> valid
>> >>> with single-amenity buildings)
>> >>> The node approach has consistency issues like these buildings:
>> >>> https://www.openstreetmap.org/node/656793551 .
>> >>>
>> >>> The area approach is more consistent but doesn't really allow
>> >>> multi-purpose
>> >>> buildings.
>> >>> A third, lesser used method is to use part of the simple indoor
>> >>> tagging
>> >>> schema. I've used a simplified version of this for this restaurant:
>> >>> https://www.openstreetmap.org/way/580985564 .
>> >>> This approach uses two overlapping ways, one for the general building
>> >>> (tagged building=house) and one for the restaurant on the ground floor
>> >>> (tagged room=restaurant and of course amenity=restaurant).
>> >>>
>> >>> Drawbacks of this are for one that the two ways fully overlap. This
>> >>> triggers
>> >>> the JOSM validator and probably some QC tools. Secondly renderers
>> >>> might have
>> >>> trouble placing the icons and house numbers of multiple areas like
>> >>> this.
>> >>> Luckily both these problems could be fixed. The positives are of
>> >>> course:
>> >>> consistency and the possibility for multiple amenities (using the
>> >>> level=*
>> >>> key).
>> >>>
>> >>> What do you all think of this approach?
>> >>>
>> >>> Kind regards,
>> >>> Pieter (Ubipo)
>> >>>
>> >>> ___
>> >>> Talk-be mailing list
>> >>> Talk-be@openstreetmap.org
>> >>> https://lists.openstreetmap.org/listinfo/talk-be
>> >>>
>> >
>> > ___
>> > Talk-be mailing list
>> > Talk-be@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-be
>> >
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] Nodes or areas to tag amenities

[Marc Gemis]

o, I forgot, what about a restaurant that occupies multiple floors ?



On Wed, Apr 18, 2018 at 11:55 AM, Marc Gemis  wrote:
> The idea of using indoor mapping is good, and it's probably the future
> to solve all the problems you mention. (we had a similar discussion
> last Friday on the Riot channel)
>
> Some remarks:
>
> - does it make sense for a "room" to have an house number and a street
> ? I would expect those on the building, and floor or level or so on
> the room.
> - I'm not familiar enough with the simple  indoor tagging, but I would
> expect that a restaurant exists of multiple rooms (dining, toilets,
> kitchen) not just one.
> - On the Riot channel the entrance to the restaurant was also seen as 
> important.
>
> m
>
> On Wed, Apr 18, 2018 at 10:06 AM, Ubipo .  wrote:
>> Everyone,
>>
>> A long standing question for osm mapping in cities is wether to tag
>> amenities in multi-purpose buildings as:
>> - a separate node inside the building's way
>> - the building itself, using both building=house and amenity=* (only valid
>> with single-amenity buildings)
>> The node approach has consistency issues like these buildings:
>> https://www.openstreetmap.org/node/656793551 .
>>
>> The area approach is more consistent but doesn't really allow multi-purpose
>> buildings.
>> A third, lesser used method is to use part of the simple indoor tagging
>> schema. I've used a simplified version of this for this restaurant:
>> https://www.openstreetmap.org/way/580985564 .
>> This approach uses two overlapping ways, one for the general building
>> (tagged building=house) and one for the restaurant on the ground floor
>> (tagged room=restaurant and of course amenity=restaurant).
>>
>> Drawbacks of this are for one that the two ways fully overlap. This triggers
>> the JOSM validator and probably some QC tools. Secondly renderers might have
>> trouble placing the icons and house numbers of multiple areas like this.
>> Luckily both these problems could be fixed. The positives are of course:
>> consistency and the possibility for multiple amenities (using the level=*
>> key).
>>
>> What do you all think of this approach?
>>
>> Kind regards,
>> Pieter (Ubipo)
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>

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

Re: [OSM-talk-be] Nodes or areas to tag amenities

[Marc Gemis]

The idea of using indoor mapping is good, and it's probably the future
to solve all the problems you mention. (we had a similar discussion
last Friday on the Riot channel)

Some remarks:

- does it make sense for a "room" to have an house number and a street
? I would expect those on the building, and floor or level or so on
the room.
- I'm not familiar enough with the simple  indoor tagging, but I would
expect that a restaurant exists of multiple rooms (dining, toilets,
kitchen) not just one.
- On the Riot channel the entrance to the restaurant was also seen as important.

m

On Wed, Apr 18, 2018 at 10:06 AM, Ubipo .  wrote:
> Everyone,
>
> A long standing question for osm mapping in cities is wether to tag
> amenities in multi-purpose buildings as:
> - a separate node inside the building's way
> - the building itself, using both building=house and amenity=* (only valid
> with single-amenity buildings)
> The node approach has consistency issues like these buildings:
> https://www.openstreetmap.org/node/656793551 .
>
> The area approach is more consistent but doesn't really allow multi-purpose
> buildings.
> A third, lesser used method is to use part of the simple indoor tagging
> schema. I've used a simplified version of this for this restaurant:
> https://www.openstreetmap.org/way/580985564 .
> This approach uses two overlapping ways, one for the general building
> (tagged building=house) and one for the restaurant on the ground floor
> (tagged room=restaurant and of course amenity=restaurant).
>
> Drawbacks of this are for one that the two ways fully overlap. This triggers
> the JOSM validator and probably some QC tools. Secondly renderers might have
> trouble placing the icons and house numbers of multiple areas like this.
> Luckily both these problems could be fixed. The positives are of course:
> consistency and the possibility for multiple amenities (using the level=*
> key).
>
> What do you all think of this approach?
>
> Kind regards,
> Pieter (Ubipo)
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] Ourthe = path?

[Marc Gemis]

In dit geval zal het wel fout zijn, maar bij een rivierbedding die bv.
de helft van het jaar droog staat en dan als pad gebruikt wordt, denk
ik dat de combinatie wel kan.

m.

p.s. is er al iemand bezig met het terugdraaien + contacteren van de mapper ?

2018-04-12 1:06 GMT+02:00 Gerard Vanderveken :
> Goedendag,
>
> Hier heeft er eentje bij de rivier Ourthe een highway=path toegevoegd.
> Is zo een dubbel gebruik van waterway en highway tags korrekt?
>
> Met vriendelijke groeten,
> Gerard
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] Conflation OpenData Brussels

[Marc Gemis]

Hallo,

The more automated the conflation is done, the more strict the import
guidelines have to be followed.

There are a number of tools that come to my mind:

- JOSM with OpenData & Conflation plugins
- Glenn's tool for GRB building import might be adaptable for your use
- Ilya Zverik's conflation tool that is currently used for the gas
station import  preparation.
- The tool the UK community uses to prepare their quarterly projects.
They did something around schools last last year, where the goal was
that the participants solved the conflation problem in their local
area.

Conflation won't work easily for

- road surfaces: you might have to split existing OSM ways representing streets
- 3D buildings: It's very likely that their model does not match the
simple 3D model of OSM. Their is a separate repository for 3D models
now.
- PT should be rather complete. Contact Polyglot to see whether the
data is so different from what we "imported" already


IMHO, manual conflation is preferable. Given the many mismatches
between any company/government data set and the reality, a check by a
human is necessary.

regards

m

p.s. I can look up more information or contact info for particular
tools if you want.

On Tue, Apr 3, 2018 at 9:22 PM, eMerzh  wrote:
> Hi all :)
>
> I'm just discovering the data sets that are in
> http://opendatastore.brussels/  (brussels region)
> and some of them might be really interesting for osm.
> Like :
> - school list
> - streets surfaces
> - 3d buildings
> - parkings
> - transports stop poles
> and much more
>
> , but I was wondering if there was an "easy" way to do the conflation...
> automatically or semi-manually ...
> for now the only way I see is to transform data, put them in a postgis  then
> doing all the work manually... but...
> ** there must be a better way **
> no?
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] Bonjour a tous

[Marc Gemis]

Je ne comprend pas quel lien vous utilisez:
https://www.openstreetmap.org, https://tiles.openstreetmap.org,
https://nominatim.openstreetmap.org ?

Il y a 2 document qui donne des limites pour les serveurs d'
OpenStreetMap Foundation:
https://operations.osmfoundation.org/policies/tiles/ et
https://operations.osmfoundation.org/policies/nominatim/

m.

2018-04-03 12:55 GMT+02:00 Philippe Bastin :
> Dans le cadre d'une application je voudrais joindre un lien vers les carte
> OSM
>
> Y a-t-il une limite ou les serveurs peuvent gérer n'importe quel flux
>
> Je me pose la question vu que sur OpenCage par exemple ils mettent des
> limite de récupération sur les données
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] How to request arbitration?

[Marc Gemis]

Did you contact the owner of the airfield to find out how they name it
? Did you find a sign along the street pointing to the airfield with a
name ? Is there a name sign at the entrance ? Is there an official
document  from a government which mentions a name ?

If all of those questions return false, i.e. no name, then the
airfield has no name. Maybe there are a few other places where we can
look for the item of items, but making them up from ones armchair is
certainly not one of them.

No everybody gives their house, private tennis court, driveway or
airfield a name. So noname=yes might be the only thing we can do. We
should not make up names as "Airfield of Family Anderson", "Airfield
near road N111" or whatever.

Regards

m.


p.s. @Pieter, SomeoneElse, who participates in the changeset
discussion is member of the DWG.

On Sun, Apr 1, 2018 at 11:08 PM, Karel Adams  wrote:
> I am in a bitter dispute with a couple of mappers who absolutely refuse to
> accept a "name=*" tag on an aerodrome because officially it has no name -
> indeed it figures in no official document.
>
> My point of view is that an "invented" name - which can be discussed, of
> course - is better than no name at all but they are quite adamant. How to
> address this?
>
> For the details: see https://www.openstreetmap.org/changeset/57717417 and
> https://www.openstreetmap.org/way/573934869
>
> https://wiki.openstreetmap.org/wiki/Names has been called in but I found
> nothing there to indicate only official names should be mentioned.
>
> This seems really a case for arbitration, but how to request it?
>
> Karel
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] OSM Belgium Local Chapter application, community feedback wanted

[Marc Gemis]

I have confidence that the people behind the application know what
they do and I hope that a local chapter will be beneficial for
OpenStreetMap in Belgium.

regards

m.

On Fri, Mar 30, 2018 at 8:41 AM, joost schouppe
 wrote:
> Martijn from the OpenStreetMap Foundation had some trouble reaching talk-be,
> so I'm sending this message on his behalf. Please keep his mail in the
> conversation!
> ---
>
> French / Dutch below.
>
> Hi all,
>
> You may be aware that OSMbe has applied to become an official Local Chapter
> of the OpenStreetMap Foundation. As part of the application process, I am
> asking you, the community, to share any questions, comments or concerns that
> you have, so we can address them.
>
> You can find all the information about this Local Chapter application on the
> wiki:
> https://wiki.osmfoundation.org/wiki/Local_Chapters/Applications/Belgium
>
> We will close this round of discussion two weeks from now (April 11th).
> I am looking forward to hearing your responses.
>
> Best regards,
> 8<8<8<8<8<8<8<
> Beste allemaal,
>
> Jullie hebben wellicht vernomen dat OSMbe zich kandidaat heeft gesteld om
> een officieel 'Local Chapter' van de OpenStreetMap Foundation te worden. Als
> onderdeel van het proces nodig ik de Belgische community namens de
> Foundation uit om vragen of eventuele bezwaren kenbaar te maken.
>
> Alle informatie over de kandidatuur is te vinden op de OSMF wiki:
> https://wiki.osmfoundation.org/wiki/Local_Chapters/Applications/Belgium
>
> Deze consultatieronde duurt twee weken en sluit op 11 april. Ik kijk uit
> naar jullie reacties.
>
> Beste groeten,
> 8<8<8<8<8<8<8<
> Vous êtes peut-être déjà au courant mais OSMbe a soumis une demande pour
> devenir un Chapitre Local de la Fondation OpenStreetMap.
> Dans le cadre du processus de demande, je vous demande, à vous la
> communauté, de poser vos questions, vos commentaires ou vos préoccupations
> afin que nous puissions y répondre.
>
> Vous pouvez trouver toutes les informations nécessaires au sujet de cette
> demande sur le wiki :
> https://wiki.osmfoundation.org/wiki/Local_Chapters/Applications/Belgium
>
> Nous clôturerons cette discussion dans 2 semaines.
> J'ai hâte de lire vos réponses.
>
> Bonne journée.
> --
> Martijn van Exel
> Secretary, OpenStreetMap Foundation
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] volunteers needed in Mons, Namur and Liege for the national mapathon

[Marc Gemis]

Feel free to take some slides of
https://docs.google.com/presentation/d/1IyyzXXyBWb6sO0U4Z5mROAmChKDPcaVCMa0ozG4h_q8/edit?usp=sharing

(I will try to make the presentation more consistent -- all black on white)

It might be hard to understand since I do not write notes under
slides, and avoid to put text on them.

Idea is:
*what is mapathon
* what is mapping (in the context of  the mapathon.)
* why (the comparison with 3 maps & aerial imagery)
* what is OSM ( I do not plan to explain al details in the graph, was
recovered from another, more detailed presentation)
* When was HOT created  (after Earthquake in Port-au-Prince 2010)
* task manager
* validators
* Missing Maps
 * MapSwipe (nice to see it was used as pre-scan of the area)
* On-the-ground mapping (Nathalie Sidibe)
- Further contact via osm.be (contact page)


regards

m

On Tue, Mar 20, 2018 at 11:15 AM, joost schouppe
 wrote:
> Hi,
>
> We've found volunteers to help out with the mapping activity in most of the
> cities participating in the National Mapathon this Saturday.
> But Mons and Namur would be very happy to have a volunteer too!
> You can decide yourself what to do, but it could include giving the "how to
> map introduction", walking around to look for problems and validating data.
>
> Reply here, in a private mail or register on Meetup (and be sure to mention
> the city/cities you could help out):
> https://www.meetup.com/nl-NL/OpenStreetMap-Belgium/events/247922954/
>
> --
> Joost Schouppe
> OpenStreetMap | Twitter | LinkedIn | Meetup
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] Can this site help to improve data ????

[Marc Gemis]

People use that to scan out-of-copyright maps and make them available
in editors.
Only useful for "old" things: such as historic boundaries, historic
buildings,  etc.

The Irish community used that side to map all their historic boundaries.


regards

m

On Sat, Mar 3, 2018 at 5:58 PM, Jakka  wrote:
> Hoi,
> Came across this site... Is it from any use?
> http://mapwarper.net/
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] low emission zones

[Marc Gemis]

Is the R10 part of the LEZ ?


On Fri, Feb 2, 2018 at 8:50 AM, joost schouppe  wrote:
> Jo, that's right. The Antwerp one was supposed to be "everything within the
> ring road". But you need to put the infrastructure somewhere, and then the
> polygon needs to reflect that infrastructure exactly (i.e. it should be
> impossible to get fined if you stay out of the polygon). I was involved in
> this fine-tuning in my previous job.
>
> We still need to translate the access restrictions into tags.
>
> --
> Joost Schouppe
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] temporary cycle routes

[Marc Gemis]

The road properties are mapped on the road. The relation (also for
motorways) should not impose this. The E34-relation contains segments
with traffic signals, so it's not all freeway/motorway.
We should differentiate between fiets-o-strade-the-cycleway and
fiets-o-strade-the-route. The latter can contain cycleways and
residential roads imho.

Maybe we should invent something like
highway=cycleway;cycleway=fiets-o-strade for the former.

On Fri, Feb 2, 2018 at 8:47 AM, joost schouppe  wrote:
> @Ben: I was also thinking about proposed, but I don't like how this is not
> in the main tag. Instead of route=bicycle + state=proposed, I would prefer
> something like route:proposed=bicycle. Then you automatically break data-use
> that hasn't heared about these 2000 objects worldwide that have a breaking
> extra tag. I can see how that would be annoying. Still, the specialists
> (cycle layer, waymarkedtrails) seem to know about it, so I suppose that ship
> has sailed.
>
> @all: so it would be OK to map "official detours", if signposted.
>
> Subquestion: But a Fietsostrade is more than a cycle route, it also comes
> with certain assumptions about road properties (much like a car motorway
> does). The official detour would definitely be missing those features. I
> would say that as long as there is no one-on-one between the route and the
> road features, data users should not make assumptions about "this is part of
> a fietsostrade route, hence it will have fietsostrade infrastructure". And
> we should map those properties that make it special on the segments only.
> The alternative would be to have two types of relations or two types of
> roles within a relation.
>
> --
> Joost
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] temporary cycle routes

[Marc Gemis]

I would only map them if they are signposted. So if there are signs
indicating how you get from one dedicated fiets-o-strade section to
another via "regular" roads, no problem. If there are no signs, let
the router decide the route based on other tags.

As for the concrete that has to be placed on the ground. I'm not in
favour of mapping things that one day might be there (or were there
for that matter). There are already enough objects one have to
maintain that are actually there.

regards

m

On Thu, Feb 1, 2018 at 4:29 PM, Ben Abelshausen
 wrote:
> In London some of the routes are mapped as proposed, it's a bit annoying if
> you don't know that they are just proposed and not actually there:
>
> https://www.openstreetmap.org/relation/6691788
>
> Rendering is a dotted version of the normal line on the cycle layer:
>
> https://www.openstreetmap.org/#map=18/51.54524/-0.01871&layers=C
>
> So, not sure if we should be mapping this if they don't exist yet... but if
> it's an 'official' detour why not? Some of these routes are only virtual
> anyway and not signed at all.
>
> Cheers,
> Ben
>
> On Thu, Feb 1, 2018 at 2:55 PM, joost schouppe 
> wrote:
>>
>> Hi,
>>
>> I got an interesting question today. As the Flemish "fietsostrades"
>> (fietssnelwegen, or cycle highways) are taking shape, so they are being
>> mapped in OSM. People are already using the data, even though in reality,
>> this is till very much a project.
>>
>> In more and more places, parts are completely ready, but then just stop.
>> And in some cases, there is an "official detour" of the fietsostrade. So
>> while the infrastructure is not there yet, in a sense the route is already
>> there.
>>
>> How do you think this should be mapped, if at all?
>>
>> --
>> Joost Schouppe
>> OpenStreetMap | Twitter | LinkedIn | Meetup
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] fietsknooppunten onder een nieuwe licentie

[Marc Gemis]

Lijkt op  "BY-SA" , want "De bronvermelding moet gebeuren als volgt
‘Vlaamse Toeristische Organisaties’."
Dus moet je toelating zien te krijgen opdat vermelding op de OSM
website voldoende is.

m.

2018-01-22 19:38 GMT+01:00 joost schouppe :
> Hoi,
>
> Heeft iemand een idee of deze licentie bruikbaar is voor OSM?
>
> http://data.toerismevlaanderen.be/licenties (licentie routenetwerken)
>
> Die is wellicht van toepassing op:
> http://data.toerismevlaanderen.be/tourist/routes/cycling_node_network_v2
>
> En de meeste gerelateerde die hier staan:
> http://data.toerismevlaanderen.be/datasets?q=datasets&f%5B0%5D=category%3Aroutes%20%26%20tours
>
> --
> Joost Schouppe
> OpenStreetMap | Twitter | LinkedIn | Meetup
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] [Tagging] Way access mismatch relation route=bicycle

[Marc Gemis]

We had a similar discussion on the ring around Roeselare on the
Riot/Matrix channel.

Maybe it's time we rewrite the Belgian highway classification page to
indicate that Nxxx & Rxxx are just indications for mapping and that
traffic signs and road importance take precedence ?

m

On Fri, Jan 19, 2018 at 8:44 AM, OSMDoudou
<19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
> Thanks for the link. I hadn't discovered this page yet.
>
> On the other hand, the same page reads "Rx should also be tagged as 
> motorways".
>
> R0 Brussels, R1 Antwerp and R4 Ghent are tagged like that.
>
> But R24 Nivelles, R20 Brussels, R9 Charleroi are tagged as trunks.
>
> And R52 Tournai, R36 Kortrijk and R30 Brugge as primary.
>
> And parts of R23 Leuven are tagged as primary and some other even as 
> secondary.
>
> So, it seems nuance, interpretations and findings from the ground lead to 
> different tagging of R roads.
>
> -Original Message-
> From: Marc Gemis [mailto:marc.ge...@gmail.com]
> Sent: Friday, January 19, 2018 07:16
> To: OpenStreetMap Belgium 
> Subject: Re: [OSM-talk-be] [Tagging] Way access mismatch relation 
> route=bicycle
>
> I think 
> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Highways
> gives the solution, there needs to be an F9 sign. If not, it is a primary.
>
> regards
>
> m
>
> On Thu, Jan 18, 2018 at 10:24 AM, OSMDoudou 
> <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
>> Hello,
>>
>> Can you help with the B) part of the discussion ?
>>
>> What highway value is suitable for R50 ?
>>
>> Now that I discovered the local implicit characteristics thanks to the
>> answer to question A), trunk is probably right, but I wanted to ask
>> your views nonetheless.
>>
>> Thx.
>> 
>> From: Volker Schmidt
>> Sent: ‎18-‎01-‎18 09:39
>> To: Tag discussion, strategy and related tools
>> Subject: Re: [Tagging] Way access mismatch relation route=bicycle
>>
>> I suppose Osmose uses the country specific tables in [1] The table for
>> Belgium states that bicycle=no is implicit for "highway=trunk".
>> Hence the short way in question would need to have the additional tag
>> "bicycle=yes" for bicycle routing to pass along that cycle lane.
>> The road signs out there seem to be consistent, there are "no-bicycle"
>> sign along the ring road, except for this short piece.
>>
>> Your second point regarding the road classification trunk is a
>> different issue, that needs to be discussed with the Belgian community.
>>
>> [1]
>> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restri
>> ctions
>>
>> On 17 January 2018 at 22:45, OSMDoudou
>> <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
>>>
>>> Hello,
>>>
>>>
>>>
>>> This is a two-fold question in fact.
>>>
>>>
>>>
>>> (A)
>>>
>>>
>>>
>>> Osmose raises error "Way access mismatch relation route=bicycle" [1]
>>> on a segment of the R50 highway [2] [3].
>>>
>>>
>>>
>>> I'm guessing it's because the segment is part of relation for a bike
>>> route but it's tagged as trunk (as the rest of R50), and a trunk
>>> would imply a restriction for bicycles.
>>>
>>>
>>>
>>> Although, I see such an implication for motorways [4], I don't see it
>>> for trunks [5].
>>>
>>>
>>>
>>> Do you know what causes the access mismatch, because I don't see it
>>> from the tags ?
>>>
>>>
>>>
>>> (B)
>>>
>>>
>>>
>>> This issue raises the question whether R50 should be tagged as trunk
>>> in the first place.
>>>
>>>
>>>
>>> The Wiki page [6] refers to notions like "high performance" and road
>>> signs F9. But the road is limited to 70 km/h and there are no F9
>>> signs on the entries and exits of R50, only C19 "No entry for
>>> pedestrians" and C11 + C9 "No entry for bicycles" + "No entry for
>>> mopeds (and mofas)", which tend to confirm it's not a trunk.
>>>
>>>
>>>
>>> I wonder if primary wouldn't be more accurate classification,
>>> although the Wiki refers to a "highway linking large towns" [7],
>>> which is not the case here as the highway is a ring around the city not a 
>

Re: [OSM-talk-be] [Tagging] Way access mismatch relation route=bicycle

[Marc Gemis]

I think 
https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Highways
gives the solution, there needs to be an F9 sign. If not, it is a
primary.

regards

m

On Thu, Jan 18, 2018 at 10:24 AM, OSMDoudou
<19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
> Hello,
>
> Can you help with the B) part of the discussion ?
>
> What highway value is suitable for R50 ?
>
> Now that I discovered the local implicit characteristics thanks to the
> answer to question A), trunk is probably right, but I wanted to ask your
> views nonetheless.
>
> Thx.
> 
> From: Volker Schmidt
> Sent: ‎18-‎01-‎18 09:39
> To: Tag discussion, strategy and related tools
> Subject: Re: [Tagging] Way access mismatch relation route=bicycle
>
> I suppose Osmose uses the country specific tables in [1]
> The table for Belgium states that bicycle=no is implicit for
> "highway=trunk".
> Hence the short way in question would need to have the additional tag
> "bicycle=yes" for bicycle routing to pass along that cycle lane.
> The road signs out there seem to be consistent, there are "no-bicycle" sign
> along the ring road, except for this short piece.
>
> Your second point regarding the road classification trunk is a different
> issue, that needs to be discussed with the Belgian community.
>
> [1]
> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions
>
> On 17 January 2018 at 22:45, OSMDoudou
> <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
>>
>> Hello,
>>
>>
>>
>> This is a two-fold question in fact.
>>
>>
>>
>> (A)
>>
>>
>>
>> Osmose raises error "Way access mismatch relation route=bicycle" [1] on a
>> segment of the R50 highway [2] [3].
>>
>>
>>
>> I'm guessing it's because the segment is part of relation for a bike route
>> but it's tagged as trunk (as the rest of R50), and a trunk would imply a
>> restriction for bicycles.
>>
>>
>>
>> Although, I see such an implication for motorways [4], I don't see it for
>> trunks [5].
>>
>>
>>
>> Do you know what causes the access mismatch, because I don't see it from
>> the tags ?
>>
>>
>>
>> (B)
>>
>>
>>
>> This issue raises the question whether R50 should be tagged as trunk in
>> the first place.
>>
>>
>>
>> The Wiki page [6] refers to notions like "high performance" and road signs
>> F9. But the road is limited to 70 km/h and there are no F9 signs on the
>> entries and exits of R50, only C19 "No entry for pedestrians" and C11 + C9
>> "No entry for bicycles" + "No entry for mopeds (and mofas)", which tend to
>> confirm it's not a trunk.
>>
>>
>>
>> I wonder if primary wouldn't be more accurate classification, although the
>> Wiki refers to a "highway linking large towns" [7], which is not the case
>> here as the highway is a ring around the city not a road between cities.
>>
>>
>>
>> What type of road would you qualify the entire R50 ?
>>
>>
>>
>> Thx.
>>
>>
>>
>> [1] http://osmose.openstreetmap.fr/en/error/15216104253
>>
>> [2] http://www.openstreetmap.org/browse/way/251684307
>>
>> [3] https://goo.gl/maps/khpwvm8kxQw
>>
>> [4] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway
>>
>> [5] https://wiki.openstreetmap.org/wiki/Trunk
>>
>> [6] https://wiki.openstreetmap.org/wiki/Road_signs_in_Belgium
>>
>> [7] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dprimary
>>
>>
>> ___
>> Tagging mailing list
>> tagg...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] How to avoid that names are on all buildings

[Marc Gemis]

so the area is called "Clintonpark", so an "area" should get that
name. The area is "everything", i.e. the buildings, the parking lots,
the grass between the buildings, etc.
now we need to determine what that area represents. It could be e.g. a
landuse=residential.



On Wed, Jan 17, 2018 at 1:44 PM, Tim Couwelier  wrote:
> Pitching in for a second, as it's my initial tag that got the ball rolling.
>
> The name 'Clintonpark' indicates the combined area of the buildings and
> their respective parkinglots, and is actually used as such.
> It's not a 'street name', as the buildings have house numbers referencing
> 'Ter Reigerie', the street passing next to it.
>
> At present, all the seperate buildings are tagged with the name
> 'Clintonpark', which is cluttered (and looks a bit messy), but isn't
> entirely correct either.
>
>
>
>
> 2018-01-17 12:49 GMT+01:00 Marc Gemis :
>>
>> To answer how you have to map this, you first have to answer: what is
>> "Clintonpark" ?
>>
>> - an area
>> - a collection of buildings ?
>> - a collection of identically named buildings ?
>>
>> m.
>>
>> On Wed, Jan 17, 2018 at 9:24 AM, Jakka  wrote:
>> > Hi,
>> >
>> > Every building with a different house number is a office and named
>> > "Clintonpark". Is this not to much same names on map.
>> > I tried to put it in relations but validator do not liked it, building,
>> > parking there are sharing same highways.
>> > Is there a need solution.
>> >
>> >
>> > https://www.openstreetmap.org/note/1263904#map=17/50.95775/3.10242&layers=N
>> >
>> > thx
>> >
>> >
>> > ___
>> > Talk-be mailing list
>> > Talk-be@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-be
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] How to avoid that names are on all buildings

[Marc Gemis]

To answer how you have to map this, you first have to answer: what is
"Clintonpark" ?

- an area
- a collection of buildings ?
- a collection of identically named buildings ?

m.

On Wed, Jan 17, 2018 at 9:24 AM, Jakka  wrote:
> Hi,
>
> Every building with a different house number is a office and named
> "Clintonpark". Is this not to much same names on map.
> I tried to put it in relations but validator do not liked it, building,
> parking there are sharing same highways.
> Is there a need solution.
>
> https://www.openstreetmap.org/note/1263904#map=17/50.95775/3.10242&layers=N
>
> thx
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] AIV import tool - discussie

[Marc Gemis]

vanaf hier 
https://matrix.to/#/!SqvNXrBsvdGHYRyota:matrix.org/$1515412099750267NwXZF:matrix.org

Dit geeft een pagina met heel wat links. Click bv. the link onder
'Access Message' naast Riot (als dat je client is), maw
https://riot.im/app/#/room/!SqvNXrBsvdGHYRyota:matrix.org/$1515412099750267NwXZF:matrix.org

m.

2018-01-10 9:18 GMT+01:00 Jakka :
> Vanaf waar kan ik deze herlezen in riot ?
> Ben aan scrollen geweest maar nie direct conversatie gevonden
>
>
>
> Op 9/01/2018 om 9:51 schreef Marc Gemis:
>>
>> (In Dutch as it is about the import of buildings in Flanders).
>>
>> Gisteren was er een levendige discussie op het Matrix (aka Riot)
>> channel over de import.
>> Het ging hierbij om het volgende: momenteel zorgt de tool ervoor dat
>> je de gebouwen in JOSM krijgt met de building=house of de
>> building=shed tag. Dit is gebaseerd op de GRB data die enkel die types
>> kent.
>>
>> De maker van de tool, Glenn, heeft deze keuze gemaakt omdat die in
>> veel gevallen correct is. Hij gaat er verder van uit dat de persoon
>> die de import doet, wel het gebouw type zal aanpassen.
>>
>> Een aantal mensen, waaronder ikzelf vinden dat building=yes een betere
>> keuze is, omdat dat altijd juist is, zelfs als het gebouw een
>> een-gezin woning (house) is. Je hoeft dan niet onmiddellijk het type
>> aan te passen.
>>
>> Het gaat hier dus over een default (house) die meestal juist is, maar
>> verkeerd is voor bv. industriële gebouwen, kerken, kantoorgebouwen,
>> flatgebouwen, of een minder nauwkeurige tag, die informatie verliest
>> bij echte "building=house), maar wel altijd correct is.
>>
>> Glenn gaat nu kijken of er misschien iets kan gedaan worden door te
>> kijken naar de landuse waarin het gebouw gaat terecht komen.
>>
>> Wil je deelnemen aan dit soort discussies, schrijf je  dan in op ons
>> chat channel in Matrix/Riot.
>>
>> mvg
>>
>> m
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

[OSM-talk-be] AIV import tool - discussie

[Marc Gemis]

(In Dutch as it is about the import of buildings in Flanders).

Gisteren was er een levendige discussie op het Matrix (aka Riot)
channel over de import.
Het ging hierbij om het volgende: momenteel zorgt de tool ervoor dat
je de gebouwen in JOSM krijgt met de building=house of de
building=shed tag. Dit is gebaseerd op de GRB data die enkel die types
kent.

De maker van de tool, Glenn, heeft deze keuze gemaakt omdat die in
veel gevallen correct is. Hij gaat er verder van uit dat de persoon
die de import doet, wel het gebouw type zal aanpassen.

Een aantal mensen, waaronder ikzelf vinden dat building=yes een betere
keuze is, omdat dat altijd juist is, zelfs als het gebouw een
een-gezin woning (house) is. Je hoeft dan niet onmiddellijk het type
aan te passen.

Het gaat hier dus over een default (house) die meestal juist is, maar
verkeerd is voor bv. industriële gebouwen, kerken, kantoorgebouwen,
flatgebouwen, of een minder nauwkeurige tag, die informatie verliest
bij echte "building=house), maar wel altijd correct is.

Glenn gaat nu kijken of er misschien iets kan gedaan worden door te
kijken naar de landuse waarin het gebouw gaat terecht komen.

Wil je deelnemen aan dit soort discussies, schrijf je  dan in op ons
chat channel in Matrix/Riot.

mvg

m

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

Re: [OSM-talk-be] OSM and SIAMU

[Marc Gemis]

https://www.wikidata.org/wiki/Wikidata:WikiProject_Roads if you need
to contact some Wikidatians on adding roads.

m.

On Thu, Nov 23, 2017 at 3:50 PM, Jo  wrote:
> If I  understood correctly every single street name of the Netherlands is
> already in Wikidata.
>
> 2017-11-23 14:31 GMT+01:00 joost schouppe :
>>
>> Jo,
>> Does Urbis hold the same authority about the correct street name as CRAB
>> does in Flanders? I've understood there might not be a single authoritaive
>> list for Brussels, but I'm not sure.
>> Do you have an idea on how it would actually work on this scale with
>> Wikidata? Do you know of some projects that use Wikidata on that scale? I'm
>> asking because I think Agentschap Informatie Vlaanderen might be really
>> interested in linking their data to Wikidata, and from there to OSM. It
>> helps that it allows for a single datamodel for any country that uses street
>> names. And thus for one single QA tool to keep street names valid anywhere
>> that model is used.
>>
>> 2017-11-22 22:11 GMT+01:00 Jo :
>>>
>>> Urbis released all the data for the Brussels region several years ago, so
>>> it should be possible to use that data like we use CRAB in Flanders.
>>>
>>> My personal preference would be to work with wikidata identifiers for
>>> every street in and around Brussels.
>>>
>>> Polyglot
>>>
>>> 2017-11-22 21:09 GMT+01:00 joost schouppe :

 Hi Nadia,

 Nice to see you here!

 I've played with the idea of unique identifiers for OSM objects myself
 before. But it remains controversial in the international community (not so
 much in Belgium). Here's an article I wrote long long time ago about it.
 It's especially useful for the comments, which outline some of the problems
 with my idea [1].
 Also relevant to get a feel for the issues is when this proposition for
 a global reviews database was discussed. Possibilities for linking were
 investigated, and adding external IDs got quite a bit of headwind.

 There has been a discussion about wikidata recently that turned so big
 that I couldn't follow at all. But at least until recently, there seemed to
 be an openness towards adding wikidata unique IDs. I don't know enough 
 about
 it to have a real opinion, but to me it sounds elegant to translate an
 official source of streetnames into wikidata objects, then adding that
 identifier to OSM. Maybe those more versed in Wikidata can explain.

 That said, I'm not sure your proposed solution is the most simple
 solution to the problem. Given that streetnames are given by the 
 government,
 in theory there is one and only possible way of writing the name. In
 Flanders, that would be the CRAB name. In the very few cases where CRAB is
 still wrong (or more to the point: the sign in the street says something
 slightly different than what CRAB says), you could have name="Name on the
 Street Sign" and something like name_official="Name in CRAB". In that
 situation, the problem is different: how do make sure all the street names
 are and stay correct in OSM. By coincidence, we are actually working 
 towards
 doing something like that. In the scope of the Road Completion project [1]
 we want to start "attribute/tag comparison" real soon. Glenn as well has
 built something that is even further along the line of being in production,
 where we look for "close to this official road, there is no OSM road with
 the same exact name".
 Similar bit different, we developed a website last Open Summer of Code,
 where official cycling network data is compared to OSM data all the time.
 That way we can make sure our Brussel cycling network is always at least as
 correct as the official data.
 It's only a few more steps (not easy ones, I know) until we can work
 this out further. Any difference in street names should then be fixed quite
 quickly. I'd rather see you guys helping out in this effort, than starting 
 a
 cumbersome import.

 As far as I know, those codes are only open data in Flanders
 (accidentally through CRAB open data). One of the few rules about "what to
 map" is that it should be verifiable (preferable by anyone, in the field).
 There are a few exceptions, but they are rather rare. As long as the
 National Registry codes are not open data, that sounds lie a real problem 
 to
 me. In fact, there is no way you can import data into OSM that is not open.
 Because then we would have to re-license OSM with the license of the
 National Registry :)

 One more thing is that using this ID will give you false certainty. You
 will get your results, most of the time. But someone might have corrected a
 segment (it used to have the name A, but it really is street B), and they
 will not know what to do with this strange ref number. So even after a
 succesful import, you woul

Re: [OSM-talk-be] OSM and SIAMU

[Marc Gemis]

Hallo Nadia,

nice to hear that the fire department is using OSM.

As for the refs for the roads. There are a number of different systems
in place for reference numbers that you do not see.
In the UK they use official_ref or admin_ref [1]
In France they have e.g. ref:FR:FANTOIR
and there is also unsigned_ref [2]

I would stick to one of those keys

Some people in the international community do no like those external
accounts, as ordinary mappers cannot easily check them. I do not think
that the Belgian community really objects to those refs. Be aware that
those refs can disappear, as mappers might not understand their
purpose.

I leave it to others to decide whether the import procedure has to be
followed to add the refs.

In case you understand German, it might be interesting to view the
presentation by this fire department [3] on using OSM.


regards

m

[1] 
https://wiki.openstreetmap.org/wiki/United_Kingdom_Tagging_Guidelines#Tagging_Road_Numbers
[2] https://wiki.openstreetmap.org/wiki/Key:unsigned_ref
[3] 
https://www.youtube.com/watch?v=1__IjaP1EY8&feature=youtu.be&list=PLTli5-lbeoibyuVe_GXqZjYqNT-P83zEp

On Wed, Nov 22, 2017 at 1:57 PM, PONCELET Nadia
 wrote:
> Hello everyone,
>
>
>
> The SIAMU (fire brigade and of urgent medical aid of the Brussels Region)
> presently uses OpenStreetMap in several of its applications, in particular
> to define preferential routes for emergency vehicles in Brussels. We work at
> the moment with Champs Libres to ensure a regular and effective integration
> of OSM updates in our internal applications.
>
>
>
> One of the problems we run into is related to street names. The SIAMU have
> its own dictionary of street names which we have associated with OSM road
> network using the ‘name’ tag. But we have some difficulties in maintaining
> this link throughout the updates.
>
>
>
> All things considered, the best solution for us would be to add some
> reference identifier to every OSM highway in Brussels. That would allow us
> to maintain the link with our internal street dictionary, even when the tag
> ‘name’ is modified.
>
>
>
> There are several possibilities for a reference id. We suggest choosing the
> national register number for public road network (made of the zip code + a
> road number). This code would have the advantage to be also usable outside
> Brussels Region. Moreover, anyone who wants to make the link between OSM and
> any administrative data containing this national register number could
> re-use it.
>
>
>
> We would like to ask for advice to the OSM community on several questions:
>
> - Do you think that a new tag ‘ref:natreg’ could be used?
>
> - In certain cases, several numbers of national register are associated to
> the street (when the street follows or crosses one or several municipal
> limits). In this case, it is preferable to use several tags or to use a
> single tag with a separator (";") between the different reference numbers?
>
> - Do you think that an automatic import of these national register numbers
> for Brussels Road network could be realized?
>
>
>
> Of course, we also plan to contribute to improve OSM objects used by the
> emergency services. A wikipage could be created listing all the tags that we
> consider important for our applications. We see a real added-value in using
> OSM in our applications (especially in term of data updates) and we hope for
> a fruitful collaboration!
>
>
>
>
>
> Nadia Poncelet (for SIAMU)
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] road completion project

[Marc Gemis]

> You can go to the overview of the challenge (what you call 'task', the
> collection of all wegenregister cases) by selecting the little 'cogs' on the
> top right and then click 'view challenge', then you get all the little task
> on one big map. This way you can select tasks  in your area.

That's great ! Now I can work in an area I'm familiar with

Question: why is the task not showing up when I just log into
MapRoulette en zoom in ?

m.

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

Re: [OSM-talk-be] road completion project

[Marc Gemis]

It would be nice if I could find limit the "tasks" to an area I'm
really familiar with or that I have surveyed. I know Joost has a map
somewhere that shows the differences.
But I might easily fix all the problems in my town without leaving the
computer right now.
I know this is not how MapRoulette works, but would be nice for this task.

wanted to write something about "mapping based on imagery", but I want
to keep it decent :-)

m.

On Tue, Nov 14, 2017 at 12:00 PM, Ben Abelshausen
 wrote:
> Marc,
>
> Thanks for the not-so-positive feedback.
>
> I'm a bit disappointed by the quality of wegenregister as a comparison basis
> (but I should have known better by now) but I'm still conviced about the
> general idea. In the beginning we had another subset of the data with only
> what we are relatively sure of coming from wegenregister but we noticed that
> the classifications don't make sense all the time. In the end we took all
> roads that had a name; at that point we discovered there are a lot of
> driveways in there with a name (ouwch!).
>
> It all comes down to: trying to detect missing stuff in OSM and I think
> there are some very good examples in the data for example these:
> http://maproulette.org/map/2789/3111729?
> http://maproulette.org/map/2789/3108600?
>
> We also ask **not to map when not sure**  so if you look at the instruction
> you will see we don't ask to copy the data but to map whatever is missing,
> by the same standards as usual. If that's not possible remotely then don't
> map.
>
> We also shouldn't copy the streetnames except when we are sure it's an
> actual road. And yes sometimes that means a guestimate of what's a driveway,
> but how's that different from what we've been doing all along based on
> imagery?
>
> If anyone else has questions, feel free! Also, don't map when you're not
> sure! It's better not to have data, compared to having bad useless data.
>
> Cheers,
> Ben
>
> On Tue, Nov 14, 2017 at 9:37 AM, Marc Gemis  wrote:
>>
>> I've tried a couple of "tasks".
>> I found it pretty hard to fill in the proper road type without being
>> familiar with the local situation.
>> The fact that Wegenregister adds a name to each and every long drive
>> way is not going to help with the OSM data quality.
>>
>> So I gave up and went back to processing my surveys.
>>
>> m.
>>
>> On Tue, Nov 14, 2017 at 9:29 AM, joost schouppe
>>  wrote:
>> > Hi,
>> >
>> > Ben and I have been working on "the road completion" project for quite
>> > some
>> > time now. The idea is to build a toolchain that harvests any open data
>> > source on road networks, and turn it into a list of "possibly missing
>> > roads
>> > in OSM".
>> >
>> > For a project overview, look here:
>> > http://www.osm.be/2017/01/06/en-project-road-completion.html
>> >
>> > Because it should be scalable and easy to adapt, we started with very
>> > simple
>> > analysis methods. The idea is to make something simple that is quick to
>> > set
>> > up and easy to extend. The repository is on Github [1]
>> >
>> >
>> > We started of with Wegenregister, an extensive road dataset for
>> > Flanders. A
>> > first selection uses only roads that should be easy to map with just GRB
>> > and
>> > aerial imagery. Because feedback is essential (to correct the many
>> > mistakes
>> > in the source data, to fine-tune our processes, to avoid having a road
>> > seem
>> > missing until someone uncritically adds it), we are using Maproulette to
>> > coordinate task completion. Instructions are available on the wiki [2]
>> >
>> >
>> > We're presenting this project at the Informatie Vlaanderen Trefdag. It's
>> > a
>> > big thing that we got ourselves invited there at all! [3]
>> >
>> > If you want to help, start the task, have a look at the Github, improve
>> > the
>> > documentation, find another dataset to use, etc!
>> >
>> > 1: https://github.com/osmbe/road-completion
>> > 2:
>> >
>> > https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Road_completion_project/Instructions
>> > 3: https://overheid.vlaanderen.be/trefdag-informatie-vlaanderen
>> >
>> >
>> >
>> > --
>> > Joost Schouppe
>> >
>> > ___
>> > Talk-be mailing list
>> > Talk-be@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-be
>> >
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] road completion project

[Marc Gemis]

I've tried a couple of "tasks".
I found it pretty hard to fill in the proper road type without being
familiar with the local situation.
The fact that Wegenregister adds a name to each and every long drive
way is not going to help with the OSM data quality.

So I gave up and went back to processing my surveys.

m.

On Tue, Nov 14, 2017 at 9:29 AM, joost schouppe
 wrote:
> Hi,
>
> Ben and I have been working on "the road completion" project for quite some
> time now. The idea is to build a toolchain that harvests any open data
> source on road networks, and turn it into a list of "possibly missing roads
> in OSM".
>
> For a project overview, look here:
> http://www.osm.be/2017/01/06/en-project-road-completion.html
>
> Because it should be scalable and easy to adapt, we started with very simple
> analysis methods. The idea is to make something simple that is quick to set
> up and easy to extend. The repository is on Github [1]
>
>
> We started of with Wegenregister, an extensive road dataset for Flanders. A
> first selection uses only roads that should be easy to map with just GRB and
> aerial imagery. Because feedback is essential (to correct the many mistakes
> in the source data, to fine-tune our processes, to avoid having a road seem
> missing until someone uncritically adds it), we are using Maproulette to
> coordinate task completion. Instructions are available on the wiki [2]
>
>
> We're presenting this project at the Informatie Vlaanderen Trefdag. It's a
> big thing that we got ourselves invited there at all! [3]
>
> If you want to help, start the task, have a look at the Github, improve the
> documentation, find another dataset to use, etc!
>
> 1: https://github.com/osmbe/road-completion
> 2:
> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Road_completion_project/Instructions
> 3: https://overheid.vlaanderen.be/trefdag-informatie-vlaanderen
>
>
>
> --
> Joost Schouppe
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] Afbraak hoogspanningslijn: hoe aanpakken in OSM ?

[Marc Gemis]

razed: moet demolished: zijn (zie
https://wiki.openstreetmap.org/wiki/Key:demolished:)

2017-11-13 7:58 GMT+01:00 Marc Gemis :

> ik doe dat bij gebouwen, omdat er meer mensen zijn die zich daar mee bezig
> houden.
> Maar hoeveel mensen tekenen er nu power lines ? Ik acht de kans dat die
> terug gaat getekend worden zo klein.
> Waarom zouden we de kaart (in een editor) laten volstaan met zaken die op
> een of andere luchtfoto nog zichtbaar zijn ?
> En wanneer doen we ze dan echt weg ?
>
> Maar ja, razed: (als ze echt weg zijn) en disused: zolang ze er staan kan
> ook.
>
> m.
>
> 2017-11-13 7:53 GMT+01:00 Jo :
>
>> zou het dan niet beter zijn om disused: o.i.d. voor de tags te zetten?
>> Dan wordt ze niet meer gerenderd, maar de kans is 0 dat iemand ze opnieuw
>> zou tekenen.
>>
>> Jo
>>
>> Op 13 november 2017 om 05:16 schreef Marc Gemis :
>>
>> Aangezien we enkel mappen wat nu zichtbaar is, zou ik opteren om alles te
>>> verwijderen.
>>> Er is dan wel een hele kleine kans dat iemand ze terug gaat intekenen
>>> aan de hand van oude luchtfoto's.
>>>
>>> m.
>>>
>>> 2017-11-12 17:52 GMT+01:00 Denis Verheyden :
>>>
>>>> Dag iedereen,
>>>>
>>>>
>>>> Een tijd geleden is Elia begonnen met de afbraak van de 70kV
>>>> hoogspanningslijn Schelle-Mechelen, die niet zo ver van mijn deur loopt:
>>>>
>>>> http://www.openstreetmap.org/way/23157086
>>>> <http://www.openstreetmap.org/way/23157086>
>>>> OpenStreetMap | Way: 23157086
>>>> <http://www.openstreetmap.org/way/23157086>
>>>> www.openstreetmap.org
>>>> OpenStreetMap is a map of the world, created by people like you and
>>>> free to use under an open license.
>>>>
>>>> Voor zover ik weet zijn er deze eeuw nog niet zo veel lijnen verdwenen,
>>>> er zijn er eerder bijgekomen of sommige hebben nieuwe
>>>> draadstellen/isolatoren gekregen voor een hoger voltage.
>>>>
>>>>
>>>> De vraag is nu: hoe pak ik dit aan in OSM ? Gewoon alle palen en de
>>>> hoogspanningslijn verwijderen ?
>>>>
>>>> Of alles omzetten met een tag 'former:' of 'historic:' voor ? In dat
>>>> geval kunnen kaarten die voormalige hoogspanningslijnen weergeven nog
>>>> altijd deze lijn weergeven, terwijl in de OSM default view de lijn niet
>>>> meer getoond wordt (zoals er nu ook geen kabels meer hangen)
>>>>
>>>>
>>>> Groeten,
>>>>
>>>> Denis
>>>>
>>>>
>>>>
>>>> ___
>>>> Talk-be mailing list
>>>> Talk-be@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>>
>>>>
>>>
>>> ___
>>> Talk-be mailing list
>>> Talk-be@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>
>>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Afbraak hoogspanningslijn: hoe aanpakken in OSM ?

[Marc Gemis]

ik doe dat bij gebouwen, omdat er meer mensen zijn die zich daar mee bezig
houden.
Maar hoeveel mensen tekenen er nu power lines ? Ik acht de kans dat die
terug gaat getekend worden zo klein.
Waarom zouden we de kaart (in een editor) laten volstaan met zaken die op
een of andere luchtfoto nog zichtbaar zijn ?
En wanneer doen we ze dan echt weg ?

Maar ja, razed: (als ze echt weg zijn) en disused: zolang ze er staan kan
ook.

m.

2017-11-13 7:53 GMT+01:00 Jo :

> zou het dan niet beter zijn om disused: o.i.d. voor de tags te zetten? Dan
> wordt ze niet meer gerenderd, maar de kans is 0 dat iemand ze opnieuw zou
> tekenen.
>
> Jo
>
> Op 13 november 2017 om 05:16 schreef Marc Gemis :
>
> Aangezien we enkel mappen wat nu zichtbaar is, zou ik opteren om alles te
>> verwijderen.
>> Er is dan wel een hele kleine kans dat iemand ze terug gaat intekenen aan
>> de hand van oude luchtfoto's.
>>
>> m.
>>
>> 2017-11-12 17:52 GMT+01:00 Denis Verheyden :
>>
>>> Dag iedereen,
>>>
>>>
>>> Een tijd geleden is Elia begonnen met de afbraak van de 70kV
>>> hoogspanningslijn Schelle-Mechelen, die niet zo ver van mijn deur loopt:
>>>
>>> http://www.openstreetmap.org/way/23157086
>>> <http://www.openstreetmap.org/way/23157086>
>>> OpenStreetMap | Way: 23157086
>>> <http://www.openstreetmap.org/way/23157086>
>>> www.openstreetmap.org
>>> OpenStreetMap is a map of the world, created by people like you and free
>>> to use under an open license.
>>>
>>> Voor zover ik weet zijn er deze eeuw nog niet zo veel lijnen verdwenen,
>>> er zijn er eerder bijgekomen of sommige hebben nieuwe
>>> draadstellen/isolatoren gekregen voor een hoger voltage.
>>>
>>>
>>> De vraag is nu: hoe pak ik dit aan in OSM ? Gewoon alle palen en de
>>> hoogspanningslijn verwijderen ?
>>>
>>> Of alles omzetten met een tag 'former:' of 'historic:' voor ? In dat
>>> geval kunnen kaarten die voormalige hoogspanningslijnen weergeven nog
>>> altijd deze lijn weergeven, terwijl in de OSM default view de lijn niet
>>> meer getoond wordt (zoals er nu ook geen kabels meer hangen)
>>>
>>>
>>> Groeten,
>>>
>>> Denis
>>>
>>>
>>>
>>> ___
>>> Talk-be mailing list
>>> Talk-be@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>
>>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Afbraak hoogspanningslijn: hoe aanpakken in OSM ?

[Marc Gemis]

Aangezien we enkel mappen wat nu zichtbaar is, zou ik opteren om alles te
verwijderen.
Er is dan wel een hele kleine kans dat iemand ze terug gaat intekenen aan
de hand van oude luchtfoto's.

m.

2017-11-12 17:52 GMT+01:00 Denis Verheyden :

> Dag iedereen,
>
>
> Een tijd geleden is Elia begonnen met de afbraak van de 70kV
> hoogspanningslijn Schelle-Mechelen, die niet zo ver van mijn deur loopt:
>
> http://www.openstreetmap.org/way/23157086
> 
> OpenStreetMap | Way: 23157086 
> www.openstreetmap.org
> OpenStreetMap is a map of the world, created by people like you and free
> to use under an open license.
>
> Voor zover ik weet zijn er deze eeuw nog niet zo veel lijnen verdwenen, er
> zijn er eerder bijgekomen of sommige hebben nieuwe draadstellen/isolatoren
> gekregen voor een hoger voltage.
>
>
> De vraag is nu: hoe pak ik dit aan in OSM ? Gewoon alle palen en de
> hoogspanningslijn verwijderen ?
>
> Of alles omzetten met een tag 'former:' of 'historic:' voor ? In dat geval
> kunnen kaarten die voormalige hoogspanningslijnen weergeven nog altijd deze
> lijn weergeven, terwijl in de OSM default view de lijn niet meer getoond
> wordt (zoals er nu ook geen kabels meer hangen)
>
>
> Groeten,
>
> Denis
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] LiDAR

[Marc Gemis]

AFAIK we hardly have any elevation data, i.e. building heights. OSM
does not store elevation data for landscape features (contour lines),
although we can put ele on mountain tops.
I've seen a few blog posts on using LiDAR for OSM, but can't remember
where. There was a presentation at a SOTM: https://vimeo.com/115361043

Another issue is that even buildings not available in many areas in Belgium.

I am not aware of ele-data for communication towers and the like.

m.


On Sat, Oct 21, 2017 at 12:32 PM, Karel Adams  wrote:
> LiDAR is apparently a technique for gathering precise elevation data. Such
> data is (AFAIU) collected for most of Western Europe, and other places
> besides; and there is a tendency to make the data publicly available, too.
>
> How relevant is this for OSM? How accurate is our elevation data at present,
> for Belgium in especial? Would LiDAR data for Belgium (or parts thereof :)
> be collected, and could we get it to be publicly available? Mass import into
> OSM?
>
> Check https://rapidlasso.com/2017/01/03/first-open-lidar-in-germany/ as a
> starter, more info easily found on the www
>
> Karel (found this mentioned on an aviation forum)
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] building = staketsel

[Marc Gemis]

tip: iets ten westen en oosten van jouw staketsel, zijn er 2 meertjes in
een bos. Momenteel worden daar ook boompjes op getekend, omdat er geen
multi-polygoon gedefinieerd is voor het bos.
Heb je zin om dat te corrigeren ? Weet je hoe je een multi-polygoon moet
maken ? Vraag het anders maar, laat dan wel even je favoriete editor weten.

mvg

m.

On Thu, Oct 19, 2017 at 9:24 AM, Pieter Brusselman <
pieter.brussel...@tragewegen.be> wrote:

> @Ruben: I will fix when I come upon one.
>
> @Steven: I think I didn't notice because the rendering-color is the same
> as the 'unmapped area' around the nearby footpath (
> https://www.openstreetmap.org/way/517185144)
>
>
> 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 18/10/2017 om 21:53 schreef Steven Clays:
>
> Strange, because http://www.openstreetmap.org/way/465851481 renders
> perfectly.
>
> 2017-10-18 14:47 GMT+02:00 Ruben :
>
>> On Wed, 18 Oct 2017 10:04:01 +0200, Pieter Brusselman <
>> pieter.brussel...@tragewegen.be> wrote:
>> > Hi,
>> >
>> > Some time ago I mapped some 'man_made = pier' on the Zuidlede. Those
>> > items don't show up on the map.  Perhaps due to the rendering_style.
>> >
>> > I was looking for some examples and i found:
>> > http://www.openstreetmap.org/relation/7340858#map=18/51.0/3.73357.
>> > Here, the pier/staketsel is mapped as a 'building'.  I don't think this
>> > is realy a building :-).
>>
>> That is due to an illegal and very badly performed import.
>>
>> Do not pay attention to any tags that endless_autumn has added. (Or fix
>> them :) )
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>
>
>
> ___
> Talk-be mailing 
> listTalk-be@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-be
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] building = staketsel

[Marc Gemis]

A man_made=pier should be rendered on the default style, see e.g.
http://www.openstreetmap.org/way/22909776#map=18/51.08352/4.36580
Adding building is wrong. I don't know whether a pier mapped as an area
will show up though. Perhaps one could add area=yes.

Can you include a link to the Pier in Zuidlede ?

m.

On Wed, Oct 18, 2017 at 10:04 AM, Pieter Brusselman <
pieter.brussel...@tragewegen.be> wrote:

> Hi,
>
> Some time ago I mapped some 'man_made = pier' on the Zuidlede.  Those
> items don't show up on the map.  Perhaps due to the rendering_style.
>
> I was looking for some examples and i found: http://www.openstreetmap.org/
> relation/7340858#map=18/51.0/3.73357.  Here, the pier/staketsel is
> mapped as a 'building'.  I don't think this is realy a building :-).
>
> According to http://wiki.openstreetmap.org/wiki/Marine_navigation it
> should be 'Piers  against which boats
> can be moored should be tagged as (man_made
> =pier
> ) together with
> mooring =yes/ferry/etc. '
>
>
> --
>
> 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
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be