Re: [talk-au] Solar panels on Stucco building

[Marc Gemis]

Some additional sources:

- The project of the British OSM community:
https://wiki.openstreetmap.org/wiki/UK_2019_Q3_Project:_Solar_Power and a
YouTube video about that project:
https://www.youtube.com/watch?v=iYFBM0Dpdvw=1269s
- My Preset for Mapping in Belgium has a preset for solar panels on a roof:
https://josm.openstreetmap.de/wiki/Presets/BENELUX

Happy Mapping

m.

On Wed, Jan 6, 2021 at 12:43 PM Mat Attlee  wrote:

> In adding the Stucco building (https://www.openstreetmap.org/way/892621508)
> in Newtown, NSW I noticed it has lots of solar panels on its roof and the
> Wikipedia page goes into quite a bit of detail about the panels
> https://en.wikipedia.org/wiki/Stucco_Co-operative
>
> I'd add them myself though I am not so experienced with adding panels
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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] Facebook acquires crowdsourced mapping company Mapillary

[Marc Gemis]

On Sun, Jun 28, 2020 at 10:48 PM Mark Wagner  wrote:

> Distributed storage is one of those things that sounds good, but
> nobody's figured out how to make it actually work well.

I also wonder about privacy and security in a distributed system. Will
the distributed system only contain the blurred images? What about the
original images, will they be spread over the world, to servers ran by
unknown people, organizations, governments? Will that be an
improvement over having them owned by Facebook?

m.

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

Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Marc Gemis]

> * The CIA World Factbook says there are about 64 000 000 km of roads in
>   the world.
> * Google Street View takes 100 photos per km.
> * A photosphere from my tablet, compressed using WebP at 50% quality
>   takes 2.7 MB.

I doubt the CIA number takes into account paths and tracks.
Mapillary allows you to upload images at different times (dates) and
compare them, so unlike Google you can have 2 photos taken at the same
spot. Unlike Google most Mapillary photos are not spheres.

m.

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

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
> 

Re: [OSM-talk-ie] Why is Billy parish in Antrim shown as in Athlone Municipal District?

[Marc Gemis]

Brian,

I looked at 
https://nominatim.openstreetmap.org/details.php?osmtype=R=10993573=boundary
Normally this allows me to understand why a certain admin hierarchy is
returned. In this case, I do not understand why the distance is 0.1746
for the Athlone Municipal District.
It seems to be the admin level 8 that is closest to the centre of
Billy Parish. But as it is a relation, it should be returned when the
object is outside. (perhaps the relation was not properly closed at
the time Nominatim imported the data?)

If none here replies you should reach out to the Nominatim maintainers.

regards
m

On Tue, Apr 28, 2020 at 12:40 PM Brian Hollinshead
 wrote:
>
> During the stay at home I have added many CofI parishes to OSM based on
> single or combinations of civil parishes.
> Please see Billy Parish 10993573, it suggests it is in County Roscommon!!
> This applies to a number of others as well. Please can somebody explain why
> to me and also how or who can rectify it. While they all display OK it
> might be disconcerting to a person doing a search.
> Thank you.
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie

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

Re: [OSM-talk-ie] Why is Billy parish in Antrim shown as in Athlone Municipal District?

[Marc Gemis]

 it should be returned when the object is outside. => it should NOT be
returned when the object is outside

On Tue, Apr 28, 2020 at 3:16 PM Marc Gemis  wrote:
>
> Brian,
>
> I looked at 
> https://nominatim.openstreetmap.org/details.php?osmtype=R=10993573=boundary
> Normally this allows me to understand why a certain admin hierarchy is
> returned. In this case, I do not understand why the distance is 0.1746
> for the Athlone Municipal District.
> It seems to be the admin level 8 that is closest to the centre of
> Billy Parish. But as it is a relation, it should be returned when the
> object is outside. (perhaps the relation was not properly closed at
> the time Nominatim imported the data?)
>
> If none here replies you should reach out to the Nominatim maintainers.
>
> regards
> m
>
> On Tue, Apr 28, 2020 at 12:40 PM Brian Hollinshead
>  wrote:
> >
> > During the stay at home I have added many CofI parishes to OSM based on
> > single or combinations of civil parishes.
> > Please see Billy Parish 10993573, it suggests it is in County Roscommon!!
> > This applies to a number of others as well. Please can somebody explain why
> > to me and also how or who can rectify it. While they all display OK it
> > might be disconcerting to a person doing a search.
> > Thank you.
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie

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

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=4.4334043=17=photo=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 

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=4.4334043=17=photo=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 instance

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
>
> 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=4.4334043=17=photo=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: [Talk-de] w...@noreply.openstreetmap.org

[Marc Gemis]

Sorry for the English, feel free to reply in German

Is it possible that the mail contains a footer with a number of links
at the bottom? Messages send via the osm-website contain links to
bring you to your IN-messages on the osm.org website.

regards
m

On Tue, Jan 14, 2020 at 2:58 PM Markus  wrote:
>
> Nun hat der Mailer wieder geschrieben:
> er häbe jetzt meine Beiträge in der DB gelöscht :-(
>
> Geht die Löscherei jetzt auch in OSM los?
>
> Wie kann ich den Menschen erreichen?
>
> Gruss, Markus
>
> PS: ja, im Header habe ich nach einem Absender gesucht,
> aber die dort eingetragenen Adressen sind jetzt nicht so hilfreich:
> boun...@openstreetmap.org
> w...@noreply.openstreetmap.org
>
>
> Am 13.01.2020 um 13:06 schrieb Volker via Talk-de:
> > Hast Du mal probiert, über den Nachrichtenquelltext den Lauf der E-Mail
> > zu verfolgen?
> >
> > Am 13.01.2020 um 12:11 schrieb Markus:
> >> Habe eine interessante Mail bekommen, auf die ich gerne antworten
> >> möchte, aber die Mailadresse "noreplay" funktioniert nicht ;-)
> >>
> >> Wie finde ich die Mailadresse des Absenders?
> >>
> >> Gruss, Markus
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de

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

Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[Marc Gemis]

Tomek,

My mother tongue is Dutch. The second language I learned in school was
French. Then English. I can follow discussions in German as well.

But I'm not going to learn Esperanto, Polish, etc. anymore. I'm too
old for that.
I'm also not going to follow links to some sites that I don't know to
get to some poor translation.. So if you refuse to write in English on
this mailing list, you will no longer be able to communicate with me
and probably many others.

regards

m.

On Sun, Jan 12, 2020 at 12:16 AM Tomek  wrote:
>
> W dniu 20-01-12 o 00:04, stevea pisze:
> >> Se vi parolas Esperanton, kial vi ĝin ne uzas?
> > Because this is an English-language list.
> >
> >> Kial mi devas uzi
> >> elektronikan tradukilon por kompreni vian mesaĝon, kaj vi postulas por
> >> skribi en via gepatra lingvo? Mi ne devigas al aliaj homoj lerni mian
> >> lingvon (la polan). Kiu estas fanatikulo tie ĉi?
> > I speak some Polish, too.  Yet, I don't wish to fight with you.
> >
> > I will continue to use English here, though I will not continue to answer 
> > you when you write to the list in Esperanto (or Polish).  Why?  I repeat 
> > myself (as do others here):  because this is an English-language list.
> >
> > Peace,
> > SteveA
> EO
> Listoj por uzantoj de angla lingvo:
> https://lists.openstreetmap.org/listinfo/talk-gb
> https://lists.openstreetmap.org/listinfo/talk-us
> Tie ĉi estas ĝenerala internacia listo pri OSM-etikedoj.
>
> PL
> Listy dla użytkowników języka angielskiego:
> https://lists.openstreetmap.org/listinfo/talk-gb
> https://lists.openstreetmap.org/listinfo/talk-us
> Tutaj jest ogólna lista odnośnie znaczników OSM.
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk] mapping outside Europe

[Marc Gemis]

+1 to what Mateusz wrote.

What I meant with "write the wiki page you want to see" is: create a
new wiki page "Highways in Panama" or "Highways in South America",
preferable in Spanish and Portuguese and link to that page from one of
the existing pages.
Similar to the Highways in Africa page that I showed you earlier on.
That page did not replace the western-centric page neither.

This is also similar to
https://wiki.openstreetmap.org/wiki/Access_provisions_in_the_United_Kingdom
A page for the British community that explains how to map access for
public footpaths.
The content is not on the (general) highway, path, nor access pages.
It is a dedicated page for a certain geographic region.

So yes, the general page will remain Europe centric, but at least
there will be dedicated pages for other geographic regions. Maybe one
day, the general page will just list all regional variants, one of
them being the European variant.
But please note that the classification of highways is based on the
UK-system and that even European countries had to adapt that to their
local system. But of course, the images are similar for a British
motorway and for a German one.

This page https://wiki.openstreetmap.org/wiki/Highways has a number of
links to pages with regional variations for the classification of
highways under the "Classification" section.

So start small, with dedicated pages and do not try to change existing
pages too much. That will cause more resistance.


regards

m.

On Wed, Jan 8, 2020 at 8:57 AM Mateusz Konieczny
 wrote:
>
> 7 Jan 2020, 20:53 by ma...@anche.no:
>
> On 07/01/2020 14:38, Marc Gemis wrote:
>
> Since OSM is a do-ocracy, do not complain, but write the wiki page you
> want to see
>
>
> that's fine, and I've been doing that for Panama, and for Morocco, but I do 
> not like mapping without having reached a consensus.
>
> for that, we need other mappers to contribute to the discussion, and I never 
> managed to get any far on this in the wiki (actually, not even in the 
> changeset comments).
>
> Is the community using some FB group, Telegram channel or Discord or some 
> even more unusual
> discussion location?
>
> so you say: just revolutionize the overview for the highway tag, without 
> first reaching a consensus?
>
> Obviously no.
>
> replace the Eurocentric pictures with Panama and Morocco pics?
> an edit like this will be reverted after 15 minutes!
>
> Is a new photo differing in content (confusing for Europeans in the similar 
> way as original
> was confusing for people from Panama)? Then both should be present, one in 
> the infobox,
> one in the article text.
>
> Is the new photo usable as illustration in both cases and differs by 
> decoration
> (people are wearing different clothes etc)? Can you link an edit where it was 
> reverted
> (except cases where new non-european image was of a lower quality)?
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [Diversity-talk] Diversity 2020 Article

[Marc Gemis]

Would a Code of Conduct also apply to social media that are not
controlled by OSM/OSMF?
E.g. Twitter is currently used by a certain part of the community to
ridicule and criticize people writing on the mailing lists.

regards

m.

On Wed, Jan 8, 2020 at 1:16 AM Clifford Snow  wrote:
>
> https://www.techrepublic.com/article/diversity-why-open-source-needs-to-work-on-it-in-2020/
>  is an interesting read. The article talks about open source, but I don't see 
> any significant difference between an open data project or an open source 
> software project.
>
> What I took away from the article is
>
> We need to be more inclusive
> Men (especially over 45) don't see diversity as an issue
> Younger community members see things getting better
> We need a clear and enforced Code of Conduct to create a welcoming community
> Quotas are not the answer
>
> Just for the record, I'm a while male over (way over) 45.
>
> Happy New Year,
> Clifford
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
> ___
> Diversity-talk mailing list
> Code of Conduct: 
> https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
> Contact the mods (private): diversity-talk-ow...@openstreetmap.org

___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [OSM-talk] mapping outside Europe

[Marc Gemis]

> a more important issue (I would call it "mapping outside Europe", hence
> the subject) is for me each and every (photo)graphic explanation of the
> tagging values.  take `highway`
> (https://wiki.openstreetmap.org/wiki/Key:highway).  text are fine,
> really, but the associated pictures seem all taken in Europe, or North
> America, they have more chances to confuse the mapper based in Africa or
> South America, than helping them.

Problems such as this are easily solved by creating wiki pages for
certain areas, such as
https://wiki.openstreetmap.org/wiki/Highway_Tag_Africa

The Flemish-speaking community created
https://wiki.openstreetmap.org/wiki/NL:How_to_map_a (inspired by the
German https://wiki.openstreetmap.org/wiki/DE:How_to_map_a). We also
have dedicated pages such as
https://wiki.openstreetmap.org/wiki/NL:Jaagpad to explain typical
Belgian/Flemish situations.

Since OSM is a do-ocracy, do not complain, but write the wiki page you
want to see. As soon as you start a group of pages in a certain
language, you might get more people on board.

regards

m.

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

Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[Marc Gemis]

So isn't the only conclusion that you can make that pre-rendered tiles
fail as soon as one needs to serve a multi-language audience?

Wouldn't the best technical solution be vector tiles (or another
technology) and let the end-user choose in which language the names
are displayed?
Removing the "name" field will not solve the problems on osm.org. The
maintainers of the default style (and the other styles on osm.org)
will no longer be able to use the name field and will have to pick
another one in order to display some label. That choice will never
satisfy all needs.
E.g. a common question on help.openstreetmap.org and the different
fora is to change the labels to language X (typically English,
probably related to the nationality of the visitors).

m.

On Mon, Jan 6, 2020 at 1:50 PM Mario Frasca  wrote:
>
> Hi Tomek, and everybody.
>
> being this an English list, I'll write in English, I'm tempted to use 
> Spanish, or Italian.  my written Latin is poor.
>
> I'm sorry to disappoint you as an Esperanto fan, but I understand Polish 
> better than Esperanto.
>
> Should I "vote" on your proposal?  I consider this the wrong place for 
> holding even the discussion.  according to me, using the English language for 
> naming "South America" in the standard map is bad enough, but I do not think 
> (many) people from South America will tell you that **here**, because people 
> who agree with you will not be reading you here.  If I know the locals good 
> enough, they would want the map to be in Spanish just as they seem to have 
> the impression that the whole world (around them) speaks Spanish.  (I do not 
> know many people from Cayenne, Brazil, nor Suriname.)
>
> I disagree that the tag 'name' should be removed, and about the wikipedia 
> tag, and the fact that it generally points to the english wikipedia version, 
> too bad.  you will not solve this by removing the tag, you may try to educate 
> Latin speaking people to be more assertive, but I think it's a lost cause.
>
> I'm aware of one place in the world where they have three national languages: 
> Morocco, and what happens there is that the map uses the three national 
> languages for all names, and the map looks so clumsy this way, in particular 
> with the Amazigh name included (I have tested some locals on their knowledge 
> of the written language, and I am fairly sure that 95% of Amazigh people 
> can't even read it).  quite regularly, you see people editing the 'name' tag 
> to make it less clumsy, by removing two of the languages (those they don't 
> like, I guess).
>
> so, dear Tomek, I do not know what's the best option, but removing the 'name' 
> and the 'wikipedia' tag doesn't feel like the best one to me.  proposing it 
> here, even less.  my guess is that having a language option on the rendered 
> map would be better than this that you propose.  for some locations, I indeed 
> prefer the openstreetmap.fr map.
>
> as for the replies you are getting, I've noticed a dichotomy in the 
> community: people focusing on the actual point, and people focusing on the 
> form.  seems "cultural", and seems that European toes are less easily stepped 
> upon.  "you may try to educate English speaking people to be less assertive" 
> ;=)
>
> anyhow, cheers, and happy mapping,
>
> MF
>
> (nie piszem w twojm języku … want ik ken het niet, not enough at least.)
>
> On 05/01/2020 20:39, Tomek wrote:
>
> W dniu 20-01-06 o 02:25, stevea pisze:
>
> It's easy to goof things up and we shouldn't.
>
> EO
> Pardonu, mi ne estas provokisto, mi ne kondutas malserioze.
>
> Mi skribas en mia lingvo (pola) en internacia lingvo (Esperanto) kaj iam en 
> via lingvo (angla), kial vi ne estimas min kaj ne parolas en mia lingvo?
>
> Bonvolu koncentriĝu pri solvi la problemon pri nomoj.
>
>
>
> PL
> Przepraszam, nie jestem jakimś prowokatorem, nie wygłupiam się.
> Piszę w moim języku (polskim) w języku międzynarodowym (Esperanto) i czasami 
> w Twoim (angielskim), dlaczego Ty nie piszesz w moim języku?
>
> Proszę skoncentrować się na rozwiązaniu problemu nazw.
>
>
>
> EN
> I'm sorry, I'm not some kind of provocateur, I'm not fooling around.
> I write in my (Polish) language in the international language (Esperanto) and 
> sometimes in your (English), why don't you write in my language?
>
> Please focus on resolving the name problem.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

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] tagtransform for OSM - An effort make tagging and using OSM data easier; bridging different worlds together

[Marc Gemis]

What you describe is a rather trivial case. I agree that using OSM
requires knowledge about all possible tagging methods.

But even when you store all phone numbers as contact:phone in the
database, all data consumers will still need to offer that data when
people ask for phone. Especially in the case where the mapper said
"store phone=..." in the database and later wants to retrieve it. The
mapper does not know that the system translated that into
"contact:phone".

Who will be in charge of deciding what gets transformed into another
tag? Is shop=estate_agent and office=estate_agent exactly the same, or
does that represent a real-world difference on how estate agents work
in the world?

Another example is url and contact:url, website, heritage:website. Are
they really the same, or do some people use them for different
purposes and perhaps multiple of them on 1 object.

And what about more complex similar mappings:

- a separate cycleway or cycleway=track on the main road
- a separate footway or sidewalk=...
- postal_code on address point or a postal code boundary
- address information on building or as separate node
- POI as separate node or on the building
- traffic signals tag on the junction or as separate nodes on the incoming ways.
- the whole discussion on landuse=forest,natural=wood,landcover=trees
which are the same for some but not for others.

Those cannot be easily converted from one format to another
I fear that data consumers will always have to cope with multiple
tagging methods.

I feel it is better to properly document those "synonyms" so data
consumers are aware of them and can deal with them as they like. If we
have a bunch of scripts to help them with this process, the better.
But the database should reflect what the mapper wrote, not some
modified version of it.

regards

m.

On Thu, Dec 5, 2019 at 6:40 PM Sören Reinecke via talk
 wrote:
>
> Hey all,
>
> I currently write a specification for tranforming tags in OpenStreetMap to 
> make life of all stakeholders easier. Different tagging schemes have emerged 
> since the existence of OpenStreetMap, same are existing in parallel and a 
> newer ones deprecated old ones. Data customers without knowing the OSM 
> community much get lost, mappers use deprecated tagging schemes and newbies 
> get overhelmed by the bunch of possibilities OSM gives (they do not know 
> exactly how to map). This project aims to help developers and mappers who 
> want to take advantage of/contribute to the OpenStreetMap great database 
> which is by the way a brilliant project. This project can also help to make 
> tagging in OSM more orthogonal and more hassle free.
>
> I saw conflicting interests between OSM community, OSM developers like the iD 
> developers and data customers. A renderer might need data in another way as 
> the community contributes. The community might need another tagging scheme 
> than a renderer. I thought how we can resolve this, how we can get all sites 
> on "one table" and that is the idea I had come up with: A specification and 
> scripts helping to preprocess data for each group. But I hope to achieve in 
> long term that the community comes together with developers, approves the 
> automatic toggleable function "correcting tagging by means of the community" 
> e.g. A mapper is typing in `phone=+33 6156 785847887948950` but the converted 
> form `contact:phone=+33 6156 785847887948950` will appear in database. This 
> would make use of short-hands possible and makes life of tagging easier.
>
> The project bridges different worlds and is therefore a bridge. As bridge 
> this project should not just connect different worlds together and by 
> ensuring peace between those but also support exchange between those to 
> develop a social economy of  "send and receive" This project should support 
> the "come together" of (OSM) developers and mappers.
>
>
> A more readable version can be found here: 
> https://github.com/ValorNaram/transformation-table-osmtags/blob/master/README.md
>  and the principles can be found at 
> https://github.com/ValorNaram/transformation-table-osmtags/blob/master/principles.md
>
> ---
>
> Example 1: They want to have the phone number of a POI. There are some 
> problems with this:
>
> 1. They need to know both contact:phone and phone to get them all.
> 2. They need to support them both.
> 3. They need to remove one in case both keys are mapped on one POI. This 
> really happens, see http://overpass-turbo.eu/s/OI2.
>
> Example 2: They want to know how many POI's have changing tables (general: 
> facilities for changing a nappy of a baby). There are some problems with this 
> too:
>
> 1. They need to know both changing_table and the deprecated diaper to get 
> them all.
> 2. They need to support them both. Difficult because they're highly 
> different tagging schemes.
> 3. They need to remove one in case both keys are mapped on one POI. This 
> really happens, see 

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=tyzRIji1MXSDUcxAxoxFoQ=51.04352509997222=4.263778=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]

fs
>> 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 is van

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-nl] JOSM plugin "Ga naar" ontwikkeling.

[Marc Gemis]

Je bedoelt zoiets als dit :
https://wiki.openstreetmap.org/wiki/JOSM/Plugins/utilsplugin2#Use_custom_URL_.28Shift.2BH.29
?

mvg

m

On Thu, Oct 3, 2019 at 12:23 PM Allroads  wrote:
>
> Hallo,
>
> Er is ondertussen veel data, die we mogen gebruiken voor mapping/tagging in 
> Openstreetmap.
> Data, waarvoor we als Openstreetmap Nederland afspraken hebben gemaakt.
> Deze data is vaak in layer vorm te zien op een website, een website met in de 
> url de geografisch coördinaten en zoomniveau.
> Binnen de Openstreetmap community zijn ook enkele van deze sites ontwikkeld. 
> Om inzicht te krijgen. Hoe eigen Openstreetmap data is getagd.
> Voorbeeld: zone 30 controle, of een gebied sluitend is.
> http://mijndev.openstreetmap.nl/~marczoutendijk/openpoimap/nlvb/?map=snelheid=17=51.57365=3.70426=B0FTTFFF
>
> Wanneer alles makkelijker bereikbaar is, het in de lijst staat als controle 
> mogelijkheid, is er makkelijker te communiceren en de kwaliteit van de data 
> te verbeteren.
> En kan je meer respons verwachten!
>
> Wanneer we aan het editen zijn, wil je wel eens snel naar een site, op de 
> ingezoomde plaats.
>
> Als voorbeeld:
> We mogen nu BGT gebruiken, als layer BGT omtrekgericht in JOSM.
> Je werkt op lokaal niveau, ziet dat er iets niet klopt en wil naar “Verbeter 
> de kaart” website op locatie om een melding te maken.
> Nu moet je vele stappen nemen van/naar en inzoomen. Melding maken.
> https://www.verbeterdekaart.nl/#?geometry.x=16.5185=451931.46324746=3
>
> Wat ik mij voor stel is.
> Een node in JOSM selecteren, de knop in taakbalk “Ga naar” de website kiezen, 
> waar je naar toe wilt.
> Een Nederlandse lijst of eigen lijst, met websites om naar toe te gaan.
>
> De plugin: “Ga naar”.
>
> Wie zou willen helpen om dit tot stand te brengen? Participeren in de 
> ontwikkeling, kennis inbrengen.
> Interactie tot stand brengen van burger (vrijwilliger Openstreetmap) naar 
> Overheid. Win/win.
> Wellicht kan de Overheid, ook een taak op zich nemen. Meer meldingen is 
> betere data, vooral ook omdat de Openstreetmap mapper zeer lokaal/ingezoomd 
> werkt en vergelijkt.
> De suggestie is al bij “Verbeter de kaart” neergelegd. Financiering Kadaster 
> is moeilijk, prioriteiten. De API is mij bekend. Naar website, korte en 
> simpele stap zonder API?
> Wellicht zijn er fondsen, financiering vormen, die dit mogelijk kunnen maken. 
> Wie ziet daar mogelijkheden of zit aan het roer?
>
> Wat denken jullie van het plan en de uitvoerbaarheid?
>
>
> Met vriendelijke groet,
> Allroads.
>
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl

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

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] mapbox, (Changeset Analyzer), whodidit

[Marc Gemis]

On Tue, Sep 24, 2019 at 4:47 AM 80hnhtv4agou--- via talk
 wrote:
>
>   What are these for anyway, other than stalking ?,

Quality assurance (QA). It helps more experienced mappers to see where
new people add things.
If they spot mistakes, they should engage in a friendly conversation
via private messages or changeset comments.
Being friendly is not always easy, so sometimes messages can be too rude.
And there are people that simply do not engage in conversations, which
is often understandable, as there are so many people that make a few
edits and disappear forever.
Other people are overly protective of "their" area, and change
everything to the way they want, which is not really desirable.

In general, those tools are used to follow edits in an area, not for
following individuals.

As Warin pointed out, try to start a conversation with the other
mapper, or the local community to find out why he is changing
everything you edit.
If all else fail, you can contact the DWG, they can e.g. block the
other mapper until he reads a certain message.

Good luck (and hope you are not too disappointed in OSM due to the
behaviour of 1 individual).

regards

m

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

Re: [talk-au] What is a discussion brief?

[Marc Gemis]

Herbert,

I'm very sorry, but I have no clue what you are trying to achieve with
your series of complaints. At least I see them as complaints. it would
be helpful to me, that you give a number of real examples where the
documentation is lacking or wrong or ...
I have the feeling you either do not understand the way OSM works, or
that you do understand it, but want to change it completely.
Describing some actual problems would solve this.
Also, whenever I see someone coming to OSM with a basket full of
complaints and "demanding" OSM to change, they clash with the existing
community and leave sooner or later. Either disappointed or angry. OSM
will not radically change because some random individual does not like
the way it works.

It's also worrying to me that you write "Going into OSM and mapping is
the least of my concerns". Mapping is AFAIK, the number 1 reason for
many people in the OSM world.
Did you already map something? Was that a problem? If so, why? That
are things we can help with, by giving answers here, or updating the
Wiki.
I wonder whether we can help you if you stay vague and describe some
high level workflow or procedures.

Hopefully Discussion C  confusion about tagging bike tracks in the ACT
will be a real tagging issue.

regards

m.

On Mon, Sep 23, 2019 at 1:43 AM Herbert.Remi via Talk-au
 wrote:
>
> What is a discussion brief?
> A discussion brief serves to describe comprehensively what we know before we 
> go on to review an issue in OSM. The objective is to decide how to solve a 
> nagging problem. I resist in saying the “best way” as I think often there may 
> be no golden rule to be found.
> I think it enough that OSM is consistent and that we have a definition of 
> quality. Quality is important because when we are trying “improve” OSM it is 
> often “quality” issues, but if there is no consensus of what quality is, then 
> there will be differing opinions on what to do. This is one of the reasons 
> that discussion can become quite circular: the same word means to different 
> people different things.
> Therefore, please go through the facts presented at the top of this brief and 
> the quality definition and try to find fault with it. The information should 
> be true and factual. The quality definition should be complete (nothing 
> missing) and fit for the purpose described in the brief.
> The next step is the review of the OSM guidelines and Australia guidelines. 
> Everybody in OSM knows something of these. Even beginners need to know some 
> basics. This section is intended to provide a level playing field: it is a 
> reminder and education all in one. I hope this helps get the participation of 
> the widest possible audience, not just the knockers. Again, please go through 
> the facts presented in this section and suggest corrections if any errors are 
> found.
> The next section of the discussion brief will present a problem with 
> inconsistency or quality found in OSM and specifically in the ACT, which is 
> my area of interest. The purpose is to reconcile what is in OSM with the 
> guidelines and other known facts (laws and regulations) to decide what is the 
> best way to proceed. I think in most cases, the decision will be to revert to 
> the guidelines. There is an issue here that the guidelines are often 
> ambiguous or even conflicting. This can be resolved by changes to state, 
> country or general guidelines. Considering all the work already done, I think 
> guidelines are in many cases likely to be serviceable and that the problem is 
> more likely to arise from poor or inconsistent implementation. A social 
> solution is then best which involves bringing the current generation of 
> mappers for the area up to speed, once again. This is a perpetual task.
> The final step is to fix the problem. Going into OSM and mapping is the least 
> of my concerns. OSM mappers do that very well and it is the reason that OSM 
> is so successful. Another task that may arise from time to time is updating 
> OSM guidelines. This is a wiki job and not suited to everybody. Any football 
> team has only one goalkeeper but many players on the field. Wiki is like 
> that. You need some people doing it but many more mapping. We would hope, 
> that the wiki guidelines are the first place that the mapper goes, but if 
> not, then it will guide future controversy. At the very least, this process 
> should feed some mapper experience back improving the guidelines.
> This process could be done for other states and countries, but I am not 
> getting personally involved in that. I would like to thank, however, the many 
> people who do map areas they have never been and never likely to go. This 
> makes the OSM task a lot easier for the rest of us.
> I hope to release the first discussion brief soon.
> Discussion C: Two steps forward and one step back - confusion about tagging 
> bike tracks in the ACT.
> I look forward to your contributions.
>
> 

Re: [talk-au] topic A: the platform itself

[Marc Gemis]

Please allow me to share some experiences of moving to another
platform we had in our community.

In Belgium we moved from the mailing list to Matrix/Riot . Most active
participants in the community made the move, but in the process we
lost some people
Matrix/Riot is good for short questions, but is IMHO very bad for
longer discussions. We have 1 or 2 people that insist on using the
forum, so some things have to be repeated there.

When I look at the neighbouring countries, it notice that it is
difficult to move people from one platform to another. Some stick with
mail, some with the forum, etc.

It will probably be hard to convince people to use a new platform and
they will be the first to pinpoint any weaknesses in the new platform
and either go back to the old platform or "leave" the community.


Just my 2 cents

regards

m

On Fri, Sep 20, 2019 at 9:27 AM Edoardo Neerhut  wrote:
>
> Thanks for bringing this up Herbert.
>
> Similar sentiments
> This has actually been bothering me the last few weeks as I started to 
> realise how much of my day is spent reading through talklists that do not 
> have relevance to me or that I do not have time to respond to. For those of 
> us subscribed to multiple talklists, it becomes a very time consuming and 
> inefficient communication method.
>
> The problem is that you need to read every single one in case you miss 
> something relevant. There are lot of good conversations taking place and I 
> wish I had time to engage more, but I need to be selective.
>
> The platform
> I like the idea of a forum which can be categorised and allow the viewer to 
> make quicker decisions about which topics that would like to engage with. 
> Whether that is the OpenStreetMap forum or something else doesn't bother me. 
> Although the OpenStreetMap forum would make sense so that people can find it 
> easily.
>
> Slack is very convenient, but it is not good for important discussions 
> because the messages get archived unless you sign up to a cost prohibitive 
> plan which our community would not be able to afford.
>
> Setting a standard
> I am not sure any of this can be dictated, but it is a good discussion to 
> have and I would be interested to see how the rest of the community feels. Of 
> course asking here is inherently going to target those already using the 
> talklists, so I will bring this up in other places as well.
>
> Overall I support the interest to discuss this on a more efficient, intuitive 
> platform.
>
> On Fri, 20 Sep 2019 at 09:10, David Wales  wrote:
>>
>> I am a member of some international OSM Slack channels.
>>
>> However, because it requires a whole different app (which I only have space 
>> for on my computer), I only check it monthly at best.
>>
>> On the other hand, I read every talk-au message within a few days of 
>> original posting, because they all arrive in my email inbox on my phone.
>>
>> If the number of talk-au emails reaches overwhelming levels, it might be 
>> necessary to investigate other solutions. However, I don't think we have 
>> reached that point yet.
>>
>> If we ever did explore alternatives, I would prefer an open platform, which 
>> we can host ourselves, rather than Slack or some other proprietary system.
>>
>> Regards,
>> David
>>
>> On 20 September 2019 4:31:44 pm AEST, Frederik Ramm  
>> wrote:
>>>
>>> Hi,
>>>
>>> On 9/20/19 03:14, Herbert.Remi via Talk-au wrote:

 I will post several concerns and information on several issues, but the
 first is this platform itself.
>>>
>>>
>>> You call this platform a "forum" which is ok in the abstract sense, but
>>> note that there is actually an Australia forum in addition to this
>>> Australia mailing list
>>> (https://forum.openstreetmap.org/viewforum.php?id=24). The forum
>>> provides a slightly different user experience but is used less.
>>>
>>> In other countries, people have set up Slack channels or Facebook groups
>>> or even more esoteric channels of communication, in addition of or as a
>>> replacement for mailing lists - browse
>>> https://github.com/osmlab/osm-community-index if you want to get an idea.
>>>
>>> There's no strict rule about where the OSM community should discuss
>>> their issues, however media that requires prior registration with a
>>> third-party entity - like Slack or Facebook - are sometimes frowned upon
>>> as they give control over who can participate to that third party and
>>> might require the participant to agree to wide-ranging exploitation of
>>> their personal data by a commercial entity.
>>>
>>> In Germany where I hail from, the forum and the mailing list are used by
>>> about the same number of (but largely different) people, and since the
>>> total number of contributors is large enough to guarantee lively
>>> discussion on both, that's totally fine. Germany also has mailing lists
>>> for individual states but they are used very little, and even
>>> state-specific issues would often be discussed on the nationwide list to
>>> ensure 

Re: [OSM-talk] lines, drawing.

[Marc Gemis]

The screenshots you attached in the private mail, are those of the
iD-editor. The wiki page describes the "default" map shown on e.g.
www.openstreetmap.org.


regards

m.

On Thu, Sep 19, 2019 at 4:32 PM <80hnhtv4a...@bk.ru> wrote:
>
> The drawing do not match the current drawing on the web edit map.
>
> the colors on the edit map do not match the info page.
>
> the rail platform on the web edit page is gone.
>
> the rail platform on the page is gone.
>
> https://wiki.openstreetmap.org/wiki/File:Rendering-highway_railway_platform_area.png
>
> From: Marc Gemis
> Sent: Thursday, September 19, 2019 8:59 AM
> To: 80hnhtv4a...@bk.ru
> Cc: osm
> Subject: Re: [OSM-talk] lines, drawing.
>
> Maybe a stupid question, but what has to be fixed on that page? Can
> you provide a bit more detail?
>
>
> On Thu, Sep 19, 2019 at 3:47 PM 80hnhtv4agou--- via talk
>  wrote:
> >
> > can someone fix this page ?
> >
> > https://wiki.openstreetmap.org/wiki/LinesTab
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk] lines, drawing.

[Marc Gemis]

Maybe a stupid question, but what has to be fixed on that page? Can
you provide a bit more detail?


On Thu, Sep 19, 2019 at 3:47 PM 80hnhtv4agou--- via talk
 wrote:
>
> can someone fix this page ?
>
> https://wiki.openstreetmap.org/wiki/LinesTab
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk-ie] What are your 'must map' features?

[Marc Gemis]

Rebecca,

Thanks for the offer, but as I wrote, I do not map in Ireland. I'm a
Belgian following this mailing list.
However, I do hope someone on this list might get interested in the
topic and start mapping those objects in Ireland.
I wrote an OSM diary entry on the subject a while ago [1].  As you can
see from my list of Wikimedia Commons contributions [2], I do try to
photograph the less popular, or smaller heritage items. (and some
artwork as well)

regards

m

[1] https://www.openstreetmap.org/user/escada/diary/40782
[2] 
https://commons.wikimedia.org/w/index.php?title=Special:ListFiles/Funkyxian=1

On Tue, Sep 17, 2019 at 4:56 PM Rebecca O'Neill  wrote:
>
> I'm happy to help with some of the Wikimedia Commons element if I can.
> Right now we are running a photography competition to get people to take
> photos of National Monuments and structures listed by the National
> Inventory of Architectural Heritage and upload them to Commons:
> www.wikilovesmonuments.ie
> I'd love to see a lot of the more obscure images (that won't ever have a
> dedicated article) be used!
>
> On Tue, 17 Sep 2019 at 14:53, Marc Gemis  wrote:
>
> > (although I do not map in Ireland):
> >
> > * turn:lanes and destination signs, I find this very useful when they
> > are mapped.
> > * wayside shrines (or listed buildings in general) with photos on
> > Wikimedia Commons
> > * dog parks
> >
> > m.
> >
> > On Tue, Sep 17, 2019 at 1:26 AM Colm Moore 
> > wrote:
> > >
> > > Hi,
> > >
> > > So, for whatever reason, some of us are interested in specific
> > localities or projects, e.g. minutely mapping a whole village or
> > neighbourhood, all the roads in a county or perhaps something more
> > specific, e.g. mapping all shops in a chain or technical, e.g. I do a fair
> > bit of debugging of disconnected roads.
> > >
> > > There are some features that I feel I 'must' map, e.g. if something has
> > a reference number (road, bus stop, rubbish bin (Dublin City Council has
> > them)), I want to map it. I *really* like mapping / filling in details on
> > electrical transformers (I'm the most recent editor of 2,274 of 2,285
> > transformers mapped in Ireland). I can smell them at 50 metres! :) Or
> > rather, I've mapped so many I can tell in a neighbourhood where I am likely
> > to find one.
> > >
> > > I also run scripts through Over-Pass Turbo a few times a month,
> > searching for police stations, post office infrastructure and power
> > facilities that need their tagging improved. I also map pipelines &
> > storage  tanks. I've mapped lots of railway, but there are relatively few
> > feature left to map.
> > >
> > > Most of the time, mapping driveways an houses bores me.
> > >
> > > Colm
> > >
> > >
> > >
> > ---
> > >
> > > Never doubt that a small group of thoughtful, committed citizens can
> > change the world. Indeed, it is the only thing that ever has. Margaret Mead
> > > ___
> > > Talk-ie mailing list
> > > Talk-ie@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-ie
> >
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie
> >
>
>
> --
> PhD in Digital Media
> Project Coordinator Wikimedia Community Ireland <http://wikimedia.ie>
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie

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

Re: [OSM-talk-ie] What are your 'must map' features?

[Marc Gemis]

(although I do not map in Ireland):

* turn:lanes and destination signs, I find this very useful when they
are mapped.
* wayside shrines (or listed buildings in general) with photos on
Wikimedia Commons
* dog parks

m.

On Tue, Sep 17, 2019 at 1:26 AM Colm Moore  wrote:
>
> Hi,
>
> So, for whatever reason, some of us are interested in specific localities or 
> projects, e.g. minutely mapping a whole village or neighbourhood, all the 
> roads in a county or perhaps something more specific, e.g. mapping all shops 
> in a chain or technical, e.g. I do a fair bit of debugging of disconnected 
> roads.
>
> There are some features that I feel I 'must' map, e.g. if something has a 
> reference number (road, bus stop, rubbish bin (Dublin City Council has 
> them)), I want to map it. I *really* like mapping / filling in details on 
> electrical transformers (I'm the most recent editor of 2,274 of 2,285 
> transformers mapped in Ireland). I can smell them at 50 metres! :) Or rather, 
> I've mapped so many I can tell in a neighbourhood where I am likely to find 
> one.
>
> I also run scripts through Over-Pass Turbo a few times a month, searching for 
> police stations, post office infrastructure and power facilities that need 
> their tagging improved. I also map pipelines & storage  tanks. I've mapped 
> lots of railway, but there are relatively few feature left to map.
>
> Most of the time, mapping driveways an houses bores me.
>
> Colm
>
>
> ---
>
> Never doubt that a small group of thoughtful, committed citizens can change 
> the world. Indeed, it is the only thing that ever has. Margaret Mead
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie

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

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-nl] Hyperlink in window van een pointer werkt niet

[Marc Gemis]

Ik heb even gezocht op "leaflet keep popup up" en vond
bv https://stackoverflow.com/questions/30649919/leaflet-keep-popup-open

helpt dit ?

mvg

m

On Wed, Aug 7, 2019 at 1:42 PM Jan Pieter de Groot  wrote:
>
> Op mijn website heb ik een Openstreetmap kaart geplaatst met pointers 
> http://members.home.nl/jp.de.groot/merklappen.htm . Bij het aanklikken van 
> een pointer verschijnt een informatie window met tekst, afbeelding en of een 
> hyperlink. Als ik de hyperlink probeer aan te klikken verdwijnt de window. 
> Wat moet ik in de broncode aanpassen om de window te fixeren en de hyperlink 
> te kunnen aanklikken?
>
>
>
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl

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

Re: [OSM-talk] Isn't it nice to share?  | Re: Facebook mapping highways using AI in collaboration with OpenStreetMap

[Marc Gemis]

This "self appointed police of OSM" will probably question

- how did those companies receive the data, under which copyright?
- how did they geocode the POIs, using Google's geocoder ? (a big no-no)
- how up-to-date is this data ? Will you reimport POIs that have been
rightfully removed in OSM ?
- how will you avoid duplicates ?

all legitimate question imho.

p.s. people that keep blaming the mailing lists for bad behaviour,
really make me wonder why I keep contributing to OSM (mailing list).
Did you ever wonder that this type of constant nagging might turn off
well-meaning people as much as the people you point at turn off you?

On Fri, Aug 2, 2019 at 9:00 AM Blake Girardot  wrote:
>
>
>
> On Fri, Aug 2, 2019 at 8:00 AM Rory McCann  wrote:
>>
>>
>> Oh yes, there's nothing wrong with Facebook (and Yelp, and TripAdvisor
>> and and) having their own PoI database. But, they _could_ help us,
>> massively, by sharing it. They way they talk about OSM, you'd swear they
>> were already doing all they could to help us.
>>
>> But it's naive to think they ever will. Nothing wrong with that,
>> shareholder value and all that.
>>
>
> Hi Rory,
>
> Respectfully, it is naive to think that even if they did offer their POI 
> databases, the self appointed police of OSM would allow the POIs to be added 
> to OSM.
>
> Truthfully, it is naive to think that any mapping or data that is not 
> contributed just the way the few vocal folks who monopolize these OSM lists 
> like, will be accepted.
>
> There really is no way to win with these folks, offer a lot and they accuse 
> the contributor of trying to take over and/or destroying OSM, offer too 
> little and they accuse the users of taking advantage of OSM.
>
> Best to just do like most folks who are interested in using and contributing 
> to OSM do - unsubscribe from these lists and carry on.
>
> cheers,
> Blake
>
>
>
>
>
>
>
>
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>
>
>
> --
> 
> Blake Girardot
> OSM Wiki - https://wiki.openstreetmap.org/wiki/User:Bgirardot
> HOTOSM Member - https://hotosm.org/users/blake_girardot
> skype: jblakegirardot
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk] Ways divided by paint?

[Marc Gemis]

I agree that in this case I would tolerate it, but is it still allowed
to turn from East Mineral avenue to the  North-South, unclassified
highway?
If not, one should add turn restrictions.

regards

m

On Wed, Jul 3, 2019 at 11:11 PM Tom Pfeifer  wrote:
>
> On 03.07.2019 22:03, Jack Armstrong Dancer--- via talk wrote:
> > I've always had the impression we should not create separate traffic lanes 
> > unless "traffic flows are
> > physically separated by a barrier (e.g., grass, concrete, steel), which 
> > prevents movements between
> > said flows."
>
> Yes, I agree in general. Nearly all cases can be modelled with turn:lanes 
> (and maybe change:lanes).
>
> > https://www.openstreetmap.org/edit?changeset=70997250#map=20/39.57354/-104.98496
>
> This case -- and the aerial image is necessary to understand it -- would be 
> one of the few
> exceptions where I would tolerate the current mapping of a separate lane for 
> the left turn.
> Otherwise a navigation engine would not be able to create the appropriate 
> turn instruction at the
> point where the lane forks off. A much more complicated data model would be 
> necessary.
>
> tom
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [Talk-at] Leider im Talk Forum

[Marc Gemis]

Is https://drive.google.com/file/d/1AgN1X6I9nA64syiHi6MKPdl5R-KXaRbO/view
a violation of GDPR ? You publish names, email addresses and a website
of people who probably did not give you the permission to do that.

regards

m

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

Re: [OSM-talk] mass iD validation arrives in NYC

[Marc Gemis]

I assume that that way (powerline) was downloaded because it also has
nodes in the area you downloaded. JOSM will never complain about
objects that are not downloaded. Powerline ways tend to be long, so
the warning can easily be in another state, that is true.
Furthermore, I thought that it is not allowed to have nodes in a
powerline that do not have tags. So the suggestion to fix it, is a
valid one.
And it is not because JOSM warns about nodes without tags in a
powerline, that it allows you to solve that problem by clicking a
magical "Solve" button. You still have to add the tags yourself.

There is a magical "Solve" button in JOSM, but its capabilities are
limited (e.g. removing vehicle=yes on highway=residential and the
like), or merging 2 nodes that are lying on top of one another (at
least when the nodes have no tags).

regards

m.

On Tue, May 28, 2019 at 10:14 PM Clifford Snow  wrote:
>
>
>
> On Tue, May 28, 2019 at 10:53 AM Dave F via talk  
> wrote:
>>
>> I notice these changesets were completed in 30/60 seconds respectively.
>> I don't use iD. How is this possible? Does it have a JOSM like mass edit
>> ability?
>>
> Yes - JOSM does allow mass fixes through the validator. I've even seen 
> suggestions to fix objects on ways that are outside of the downloaded area. 
> For example, missing power poles on power lines. I don't "fix" those because 
> the validator is just looking at a node without a power pole. Often their 
> isn't a pole at that location according to the imagery.
>
> Best,
> Clifford
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

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?
> >
> > Can I come up with a definition? I like the length/width ratio, the open 
> > 

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 Antwerpen en Zelzate.  
> > There used to be a level crossing which was removed and instead they 

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=4.035847194701205=17=CemcYfldMKwaCCdn0eK2bQ=photo=0.5005982815044207=0.34925403860156434=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 wordt ook bij ons gemanifesteerd.

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-ie] Proposed mechanical edit - elimination of old-style Wikipedia links in Ireland

[Marc Gemis]

> > you can find linked Wikipedia articles with slightly different subjects
> > in different languages.
>
> All of these are yet more good reasons to tag with Wikidata, rather
> than Wikipedia.

From what I have heard there are sometimes (or often depending on the
source) mismatches between the subject of the Wikidata item and the
OSM object.
Not a problem if people only need some additional information and can
see that both subjects do not match entirely, but poses problems if a
program combines OSM and Wikidata data.

m

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

Re: [OSM-talk-ie] Proposed mechanical edit - elimination of old-style Wikipedia links in Ireland

[Marc Gemis]

AFAIK, one should use the main language of the area in which the
feature is located. I think it is supposed to follow the language used
to determine the name tag.
So for the Belgian/Flemish town Antwerpen (Antwerp in English), you
should use wikipedia=nl:Antwerpen (stad)
This links to the Wikipedia page: https://nl.wikipedia.org/wiki/Antwerpen_(stad)
Wikipedia knows that the English page is
https://en.wikipedia.org/wiki/Antwerp (perhaps by using Wikidata
internally)
This link and links to over a hundred other languages is found on the left

So either the data consumer or Wikipedia should be able to direct you
immediately to the English page if your browser settings (or app
settings) indicate that you prefer English over Dutch.
I don't know whether Wikipedia actually does this.

There is no need to add more than 100 Wikipedia links (the number of
languages for which there is an article on Antwerpen) to OSM.

This is a problem for Brussels, where OSM has no real preference for
language. Should be point to the Dutch or French version?

Note that people pointed out in the past that you can find linked
Wikipedia articles with slightly different subjects in different
languages.

I am still not really happy with this, but hey, if this is what the
majority wants, I'm not going to be a dissident.

m.

On Wed, Mar 20, 2019 at 12:45 PM  wrote:
>
> How do I tag for this situation?
>
>  How is 'the proper' language decided?
>
> Phil
>
> On Wednesday, 20 March 2019, Marc Gemis wrote:
> > The reply that I got more than a year ago when the Mapbox team was
> > doing a similar quest, was that the Wikipedia pages for multiple
> > languages are linked and that the data consumer should display the
> > page in the proper language.
> >
> > m.
> >
> > On Wed, Mar 20, 2019 at 10:53 AM  wrote:
> > >
> > > How do you intend to deal with bi-lingual areas where having Wikipedia 
> > > links in both languages is an important cultural consideration?
> > >
> > > Phil (trigpoint)
> > >
> > > On Tuesday, 19 March 2019, Mateusz Konieczny wrote:
> > > >
> > > > Mar 19, 2019, 3:10 PM by r...@technomancy.org:
> > > >
> > > > > I'm not sure why one would bother with this, but whatever.
> > > > >
> > > > It went as follows:
> > > >
> > > > - I made small prototype tool listing tourism attractions based on OSM 
> > > > data
> > > > - during development I discovered massive amount of broken wikipedia 
> > > > and wikidata tags
> > > > - due to scale and that problems were fixable by automatic edit I made 
> > > > a program for bot edits
> > > > (library parts ended on 
> > > > https://github.com/matkoniecz/osm_bot_abstraction_layer 
> > > > <https://github.com/matkoniecz/osm_bot_abstraction_layer> and
> > > > https://github.com/matkoniecz/wikibrain 
> > > > <https://github.com/matkoniecz/wikibrain> )
> > > > - I made bot edits that fixed tens of thousands objects in Poland
> > > > - in most cases (except one depending on links to TERYT, official 
> > > > government dataset in Poland)
> > > > scripts can be used in other regions
> > > > - so now I am checking whatever I would be allowed to run this script 
> > > > in various places,
> > > > including ones where some tagging issues are quite rare and would not 
> > > > justify
> > > > writing and testing an OSM bot - but running existing one is IMHO a 
> > > > good idea
> > > >
> > > > > Are they any cases where there are more than wikipedia:XX tag, and 
> > > > > what will you do in that case? What will the wikipedia tag be?
> > > > >
> > > > In case of existing matching wikipedia tag - there is no problem and 
> > > > wikipedia:XX tags
> > > > will be removed.
> > > >
> > > > Otherwise object will be skipped for a manual review.
> > > >
> > > > ___
> > > > Talk-ie mailing list
> > > > Talk-ie@openstreetmap.org
> > > > https://lists.openstreetmap.org/listinfo/talk-ie
> > > >
> > >
> > > --
> > > Sent from my Sailfish device
> > > ___
> > > Talk-ie mailing list
> > > Talk-ie@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-ie
> >
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie
> >
>
> --
> Sent from my Sailfish device
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie

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

Re: [OSM-talk-ie] Proposed mechanical edit - elimination of old-style Wikipedia links in Ireland

[Marc Gemis]

The reply that I got more than a year ago when the Mapbox team was
doing a similar quest, was that the Wikipedia pages for multiple
languages are linked and that the data consumer should display the
page in the proper language.

m.

On Wed, Mar 20, 2019 at 10:53 AM  wrote:
>
> How do you intend to deal with bi-lingual areas where having Wikipedia links 
> in both languages is an important cultural consideration?
>
> Phil (trigpoint)
>
> On Tuesday, 19 March 2019, Mateusz Konieczny wrote:
> >
> > Mar 19, 2019, 3:10 PM by r...@technomancy.org:
> >
> > > I'm not sure why one would bother with this, but whatever.
> > >
> > It went as follows:
> >
> > - I made small prototype tool listing tourism attractions based on OSM data
> > - during development I discovered massive amount of broken wikipedia and 
> > wikidata tags
> > - due to scale and that problems were fixable by automatic edit I made a 
> > program for bot edits
> > (library parts ended on 
> > https://github.com/matkoniecz/osm_bot_abstraction_layer 
> >  and
> > https://github.com/matkoniecz/wikibrain 
> >  )
> > - I made bot edits that fixed tens of thousands objects in Poland
> > - in most cases (except one depending on links to TERYT, official 
> > government dataset in Poland)
> > scripts can be used in other regions
> > - so now I am checking whatever I would be allowed to run this script in 
> > various places,
> > including ones where some tagging issues are quite rare and would not 
> > justify
> > writing and testing an OSM bot - but running existing one is IMHO a good 
> > idea
> >
> > > Are they any cases where there are more than wikipedia:XX tag, and what 
> > > will you do in that case? What will the wikipedia tag be?
> > >
> > In case of existing matching wikipedia tag - there is no problem and 
> > wikipedia:XX tags
> > will be removed.
> >
> > Otherwise object will be skipped for a manual review.
> >
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie
> >
>
> --
> Sent from my Sailfish device
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie

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

Re: [talk-au] Correct way to tag pedestrian crossings with traffic signals

[Marc Gemis]

Hallo Thomas,

I only use the second method. If I see the first one, I add the nodes
for the crossings, tag them as in the second way and remove
crossing=traffic_signals from the original node.

regards

m.

On Tue, Mar 19, 2019 at 1:04 AM Thomas Manson  wrote:
>
> I am trying to determine the best way to tag pedestrian crossings.
>
> These are the map features that I am trying to tag: 
> https://www.openstreetmap.org/node/3500829415 and 
> https://www.openstreetmap.org/node/2039208753
>
> They are currently tagged:
> crossing:traffic_signals
> highway:traffic_signals
>
> However, on the page 
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals, there 
> appears
> to be 2 ways to tag this, with the alternative being:
> highway:crossing
> crossing:traffic_signals
> for the cases (like this is) where the pedestrian crossing is not separately 
> mapped - in this case it is only a pedestrian crossing, not an intersection.
>
> My reading is that the second way is preferred for this type of crossing. Am 
> I correct?
>
> Regards,
> Thomas
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

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

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

Re: [OSM-talk] We need to have a conversation about attribution

[Marc Gemis]

>
> I am the copyright owner of my edits. You are the owner of yours.
>
> I don't recall ever giving the OSMF authority to act as my agent. Did you?


You probably agreed to
https://wiki.osmfoundation.org/wiki/Licence/Contributor_Terms, not ?

m.

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

[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: [talk-au] Our work in last two weeks

[Marc Gemis]

I think the QA tool should/could see that the sharp corner is in a point
shared with another way and that there is no reason to report a warning.


On Mon, Jan 21, 2019 at 4:26 PM Nemanja Bračko  wrote:

> Because tool doesn't know is this a special (allowed) case, or user's
> mistake. It just reports that geometry is not logical.
>
> On Mon, Jan 21, 2019 at 4:21 PM Marc Gemis  wrote:
>
>> Why does a split make any difference ? Is this a "special" feature of the
>> QA-tool you are using ?
>> The QA tool should understand that the sharp U-turn is not the only route
>> one can follow.
>>
>> m.
>>
>> On Mon, Jan 21, 2019 at 10:58 AM Nemanja Bračko 
>> wrote:
>>
>>> Hi!
>>>
>>> You've been flagged as "Impossible angle in highway" many times because
>>> of these situations:
>>> [image: 2019-01-21 10_52_54-Window-min.jpg]
>>>
>>> Just split this way (do not map it as one segment), and you will avoid
>>> to get flagged.
>>>
>>> Best Regards,
>>> Nemanja
>>>
>>>
>>>
>>> On Mon, Jan 21, 2019 at 8:51 AM Horea Meleg 
>>> wrote:
>>>
>>>> Hello all,
>>>>
>>>> As we informed you two weeks ago we started working on Australia
>>>> editing in Canberra, Perth and Melbourne.
>>>>
>>>> If you’re curious in what we did, you can find our changesets using
>>>> these links:
>>>>
>>>> AUS ALL
>>>> https://osmcha.mapbox.com/filters?aoi=22638c89-517b-45b7-889a-749a6d99ffa9
>>>>
>>>> AUS Flagged only
>>>> https://osmcha.mapbox.com/filters?aoi=9a2c90a1-6a45-4bb9-b52b-6f64b99e1cb5
>>>>
>>>>
>>>>
>>>> If you have any questions, feel free to ask us.
>>>>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Horea
>>>>
>>>>
>>>> ___
>>>> Talk-au mailing list
>>>> Talk-au@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-au
>>>>
>>> ___
>>> Talk-au mailing list
>>> Talk-au@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-au
>>>
>>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Our work in last two weeks

[Marc Gemis]

Why does a split make any difference ? Is this a "special" feature of the
QA-tool you are using ?
The QA tool should understand that the sharp U-turn is not the only route
one can follow.

m.

On Mon, Jan 21, 2019 at 10:58 AM Nemanja Bračko  wrote:

> Hi!
>
> You've been flagged as "Impossible angle in highway" many times because of
> these situations:
> [image: 2019-01-21 10_52_54-Window-min.jpg]
>
> Just split this way (do not map it as one segment), and you will avoid to
> get flagged.
>
> Best Regards,
> Nemanja
>
>
>
> On Mon, Jan 21, 2019 at 8:51 AM Horea Meleg 
> wrote:
>
>> Hello all,
>>
>> As we informed you two weeks ago we started working on Australia editing
>> in Canberra, Perth and Melbourne.
>>
>> If you’re curious in what we did, you can find our changesets using these
>> links:
>>
>> AUS ALL
>> https://osmcha.mapbox.com/filters?aoi=22638c89-517b-45b7-889a-749a6d99ffa9
>>
>> AUS Flagged only
>> https://osmcha.mapbox.com/filters?aoi=9a2c90a1-6a45-4bb9-b52b-6f64b99e1cb5
>>
>>
>>
>> If you have any questions, feel free to ask us.
>>
>>
>>
>> Best regards,
>>
>> Horea
>>
>>
>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Fwd: Editing road geometry Australia

[Marc Gemis]

On Fri, Jan 11, 2019 at 10:53 PM Warin <61sundow...@gmail.com> wrote:
>
>
> Also using the tag lanes how can the turn restrictions that exist be tagged, 
> the right 2 must turn right and the left 2 must go straight on ?
>

A combination of turn:lanes (through|through|right|right) and
change:lanes (yes|only_left|only_right|yes) and lanes=4 before the
split and lanes=2 on both ways after the split, should be enough.

AFAIK routers do not handle the change:lanes at this moment, but do a
good job based on the turn:lanes.

regards

m.

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

Re: [OSM-talk] Editing road geometry Australia

[Marc Gemis]

If you miss the on-ramp and are waiting for the traffic signals, a
router can recalculate the route in the meantime and still try to let
you turn left at the traffic signals.

m.

On Fri, Jan 11, 2019 at 1:47 PM Maarten Deen  wrote:
>
> I agree that Markus' solution is more elegant (and I was more looking to
> the offramp itself). I would normally also map it like that but I also
> don't go out of my way to correct situations like that.
> The way it is mapped now is more organic, more as you would actually
> drive. As such I don't see it as wrong.
>
> I would not add a turn restriction. For routers it is useless because
> you never get that route anyway.
>
> Regards,
> Maarten
>
> On 2019-01-11 13:23, Jem wrote:
> >> I'd map that place like that:
> > https://wiki.openstreetmap.org/wiki/File:ID_Screen_Shot_from_-32.0914374,_116.0129206.png
> >
> > I agree. And a supplementary question... would you also add a
> > no-left-turn restriction from https://osm.org/way/581948344 at
> > https://osm.org/node/5680879176? I would, and have done in the past.
> > But to be honest, I'm not sure if a turn like that (having already
> > passed the slip lane designated for the turn) is legal or not.
> >
> > On Fri, 11 Jan 2019 at 20:47, Markus 
> > wrote:
> >
> >> On Fri, 11 Jan 2019 at 07:40, Maarten Deen  wrote:
> >>>
> >>> On 2019-01-11 07:16, Petra Rajka - (p) wrote:
> >>>
> 
>  See below two cases where we would simplify the geometry:
> 
>    * -32.0914374, 116.0129206
> >>>
> >>> Is seen no big problem in how the roads are layed out there.
> >> Coming from
> >>> the motorway there is a clear divider where the offramp connects
> >> to the
> >>> Albany Highway.
> >>
> >>  and
> >>  form a
> >> double-rectangle,
> >> but there isn't such a divider. I'd map that place like that:
> >>
> >>
> > https://wiki.openstreetmap.org/wiki/File:ID_Screen_Shot_from_-32.0914374,_116.0129206.png
> >>
> >>> I have more problems with the tags of the on- and offramp. They
> >> are
> >>> mapped as motorway when they should be mapped as motorway_link.
> >> The two
> >>> bridges in the on- and offramp are mapped as motorway_link.
> >>
> >> +1. I'd also delete the descriptions like Tonkin Highway Southbound
> >> Ramp off to Albany Highway in the name tag unless the ramps are
> >> signed
> >> like that on site.
> >>
>    * -35.3409195, 149.1616891
> >>>
> >>> Ways 77001149 and 77000891 should IMHO not be mapped like that but
> >>> mapped with turn:lanes.
> >>
> >> +1
> >>
> >> Regards
> >>
> >> Markus
> >>
> >> ___
> >> talk mailing list
> >> talk@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

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, the community day w

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=a9315be566=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=e72573f541=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=94d0ca47cc=17370c2173>
>
>
>
> *When?*
>
> *Monday 4 March, 08:30-19:00*
>
> Full programme available soon

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
> https://lists.openstreetmap.org/listinfo/talk-be
>

Re: [Talk-GB] drawing internal parts of buildings

[Marc Gemis]

Did you try any of the 2 maps listed on
https://wiki.openstreetmap.org/wiki/Indoor_Mapping ?

I tried openlevelup :
https://openlevelup.net/?l=0#18/52.54051/-0.26289  but I'm not sure
whether I should be able to see the rooms on that one

m.

On Fri, Jan 4, 2019 at 12:30 AM BD  wrote:
>
> Hi all and Happy New Year,
>
> I was trying to capture Peterborough's Serpentine Green shopping centre with 
> all of its internal segments.
> And those are the results:
> https://www.openstreetmap.org/#map=18/52.54057/-0.26284
>
> Yes, I guess some of you will spot that there are no (visible) parts to the 
> shop. Well yes, but I did spent some time and now would like to ask for your 
> advise before more time is waisted.
>
> Firstly, I would like to avoid mapping this building with separate building 
> objects as this is one large shop. So solution like this is not going to 
> satisfy my requirements ;)
> https://www.openstreetmap.org/#map=18/52.54361/-0.30304
>
> Please tell me how can I get something like St. Jude Church layout from 
> Google on OSM.
> https://www.google.com/maps/@52.5826465,-0.270375,20.01z
>
> Many thanks,
> dzidek23
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [talk-au] Use of AIS message as input to OSM

[Marc Gemis]

AFAIK, OpenSeaMap is dedicated rendering based on the same
OpenStreetMap database as the map of e.g. http://www.openstreetmap.org
The OpenSeaMap project also defines certain tags that are only used
for navigation on water. See [1] for more info on how it works.

So on one hand they are already combined (use the same database), but
they are also separate (OpenSeaMap provides their own rendering of the
data).

regards

m.

[1] https://wiki.openstreetmap.org/wiki/OpenSeaMap

On Thu, Jan 3, 2019 at 7:17 AM Arthur Geeson  wrote:
>
> Hi,
>
> I would like to use the position data received from Automatic Identification 
> System (AIS) messages that are used for navigational aids for marine ships to 
> plot the position of these piles on the OSM but I am not sure if this would 
> be copy right information?
>
> Perhaps we could have a 'source - AIS' ?
>
> Looking at the OSM wiki I find that there is a 'man_made - beacon' tag.  
> Further searching I find there is an OpenSeaMap.  I am not sure why we would 
> need OpenStreetMap and OpenSeaMap should these not be combined? However if 
> they are separate so be it.  It would seem that OpenSeaMap has a number of 
> suitable icons but I was not able to search it.  Basically AIS does not seem 
> to be supported on either of the maps.
>
> MarineTraffic.com uses the OpenStreetMap to display the positions of many 
> thousands of ships around the world based on AIS input.
>
> Is anyone able to help?
>
> Thanks - Arthur
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

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

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]

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=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: [Talk-de] Feature Proposal - RFC - Empfehlung zur Verwendung von Multipolygonen

[Marc Gemis]

Wie kartieren Sie Barrieren, wenn sie die Grenze eines
Landnutzungsgebiets bilden?
Zeichnen Sie eine zweite Linie über der Landnutzung?

(Extended in English:  feel free to reply in German - reading is no
problem for me)

How do you map barriers that form the border of a landuse ? e.g. a
barbed wire fence around a meadow ?
Do you map a second way on top of the way of the landuse ? Do you
create a multi-polygon for the meadow where the outer is the barrier ?
A second way a bit bigger than the meadow ? tags of fence and meadow
on the same way ? Another solution ? )

m.
On Mon, Nov 26, 2018 at 8:46 PM Tigerfell  wrote:
>
> Hallo,
>
> ich würde gern auf ein Proposal aufmerksam machen, welches sich mit der 
> Verwendung von Multipolygonen beschäftigt. Dieses folgt im Wesentlichen der 
> Diskussion im Forum (https://forum.openstreetmap.org/viewtopic.php?id=64439 
> ).
> Das Proposal: 
> https://wiki.openstreetmap.org/wiki/DE:Proposed_features/Empfehlung_zur_Verwendung_von_Multipolygonen
>  
> 
>
> Ich möchte darauf hinweisen, dass wir uns auf die Bezeichnung "Empfehlung" 
> geeinigt haben. Damit ist gemeint, dass die Erfassung gemäß der "Empfehlung" 
> durchgeführt werden sollte, andere Vorschläge aber auch zukünftig nicht 
> verhindert werden sollen.
>
> Um die Diskussion zusammenzuhalten, empfehle ich die Diskussion über das oben 
> verlinkte Forum.
>
> Viele Grüße
> Tigerfell
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de

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

Re: [OSM-talk] OpenStreetMap Carto release v4.17.0

[Marc Gemis]

> My intention was rather to hear about some general trends,

As far as I understand,

One general trend is to be "cleaner, have less information". (e.g. the
building removal)
Another one is paler colours (e.g. parking from yellow to grey)
other landuse colour changes towards paler colours

I regularly see comments about that, (people not liking it, I haven't
read a comment about people liking it).

The one trend I really like more icons for more items, maybe even a
zoom level where you can see lanes and turn:lanes.

m.

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

Re: [OSM-talk] OpenStreetMap Carto release v4.17.0

[Marc Gemis]

> BTW: what do you consider to be a progress here? What do you like the
> most in recent changes and maybe what problems are the most visible?

The sing

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

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: [Talk-de] Gutachten [war: Re: POIs - Details - Gerichtsurteil ]

[Marc Gemis]

OSM braucht nichts. OSM ist nur eine Datenbank.

Die richtige Frage wäre "Gibt es irgendwo einen Datenverbraucher, der
daran interessiert ist, diese Informationen in der OSM-Datenbank zu
haben?"

m.
On Tue, Nov 13, 2018 at 10:16 AM  wrote:
>
> Abgesehen mal davon, das Bibliotheken mit OSM nicht viel gemeinsam haben
> und Du gerade Äpfel mit Birnen vergleichst, hängen bei Publikationen
> grundlegend andere Gesetzmäßigkeiten und vertragliche Vereinbarungen
> dahinter. Nämlich genau zwischen Autor und veröffentlichendem Verlag in
> denen u.a. solche Dinge VOR einer Veröffentlichung geregelt werden.
>
> Des weiteren ist eine Biliothek auch immer ein Archiv, selbst wenn das
> "nur" die Stadtbücherei ist und die DS-GVO kennt für derartige Fälle
> ganz konkrete Ausnahmen. Es wird zwar behauptet, dass OSM unter diese
> Ausnahmen fallen würde, aber auch nur das, eine Feststellung dazu wurde
> meines Wissens bisher nicht getroffen - andernfalls wäre die Diskussion
> zur Ausnahme nach Art. 6 [1] e oder f defakto überflüssig!
>
> Erst die Fakten schaffen, dann danach handeln und nicht anders herum!
>
> Mir fehlt bisher auch eine belastbare Stellungnahme zum Pro der
> Fragestellung, wozu OSM überhaupt derartige personenbezogene Daten
> benötigt - das solltest Du als glühender Verfechter dieser Sparte doch
> spielend für den Rest zur Diskussion stellen können. Einziges Beispiel
> bisher Deine Rückschlüsse zu besagtem Laden mit
> "belegtem-Brötchen-Verkauf" - das ist bisher kein allgemeines Interesse,
> sondern Dein persönliches!
>
> Gruß Sepp
>
>
>
> Am 13.11.2018 09:55 schrieb Martin Koppenhoefer:
> > sent from a phone
> >
> >> On 13. Nov 2018, at 09:49, sepp1...@posteo.de wrote:
> >>
> >> Immer noch bei den Persönlichkeitsrechten desjenigen, den es betrifft!
> >
> >
> > d.h. wenn eine Bibliothek ein Buch in ihren Index einträgt, muss sie
> > wegen der DSGVO den Autor fragen, ob sie seinen Namen eintragen
> > dürfen? Wenn sie von den noch lebenden Autoren keine Zustimmung haben
> > sollten sie deren Namen sicherheitshalber löschen?
> >
> >
> > Gruß, Martin
> > ___
> > Talk-de mailing list
> > Talk-de@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-de
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de

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

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] 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-nl] Caribbean Netherlands

[Marc Gemis]

I like this video that explains the differences:
https://www.youtube.com/watch?v=eE_IUPInEuc

m.
On Thu, Nov 8, 2018 at 9:39 AM Pander OpenTaal  wrote:
>
> Frederik, thanks for the changes so far. Good to wait with parts of Belgium. 
> Also good to stay clear of political issues and only use geographic 
> considerations. For me, fine not to split up Saint Martin/Sint Maarten.
>
> As for these six Dutch islands in South America, good question on how to call 
> these in a geographic way. The name Caribbean Netherlands officially only 
> refers to only three of the six islands, see 
> https://en.wikipedia.org/wiki/Caribbean_Netherlands
>
> Politically, historically and geographically, these islands can be grouped in 
> many different ways with different names, see 
> https://en.wikipedia.org/wiki/Dutch_Caribbean#Grouping_of_islands Which 
> doesn't make it easier. Calling it Dutch Caribbean is the least best name of 
> the three options, I think.
>
> Even though the name Netherlands Antilles indeed as a political entity no 
> longer exists, see https://en.wikipedia.org/wiki/Netherlands_Antilles 
> Advantage of this name, is that it doesn't favor certain islands because of 
> the current political construct (in which only a few are officially in 
> Caribbean Netherlands).
>
> I think that is the best name to use, as it is also closer to what is used in 
> the Dutch language. Nobody talks about the Caraïbische Nederlanden.
>
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl

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

Re: [Talk-us] USPS Post Boxes

[Marc Gemis]

Are you planning to run this on a regular schedule  (e.g. every month) ?

m.
On Tue, Sep 25, 2018 at 6:18 AM Leif Rasmussen <354...@gmail.com> wrote:
>
> Hi everyone,
> The opinions expressed on the USPS/United States Postal Service tagging have 
> been very mixed, with seemingly equivalent numbers of people supporting both 
> options.  Based on the following facts, I have decided to convert the tag 
> "operator"="USPS" on post boxes to "operator"="United States Postal Service".
> 1) We all agree that all USPS post boxes should have the same operator tag, 
> but disagree on the minor detail of which tag is better: "USPS" or "United 
> States Postal Service".
> 2) I saw, overall, a larger number of good arguments for expanding the 
> operator tag, including the fact that the words "United States Postal 
> Service" appear on the post boxes themselves.
> 3) Expanding USPS would be in line with the OSM "expand abbreviations" 
> guidelines.
>
> I will create the changeset Thursday evening if nobody replies with an 
> objection.  If you are strongly against this change, please stop me before 
> then!
> The changeset will do the following to post boxes tagged with 
> "operator"="USPS", "operator"="US Post Services", "operator"="US Post 
> Service", "operator"="US Postal Service", "operator"="US Postal Services", 
> "operator"="U.S. Post Services", "operator"=" U.S. Post Service", 
> "operator"="U.S. Postal Service", and "operator"="U.S. Postal Services":
> * Convert the value of "operator" to "United States Postal Service".
> * Add the tag "operator:wikidata"="Q668687".
> * Add the tag "operator:wikipedia"="en:United States Postal Service".
> * Fix any warnings or errors that come up in the JOSM validator window (such 
> as incorrect collection times format).
>
> Post offices will not be affected by this change.  If someone would like them 
> to also have uniform operator tags, they can propose that separately.
> Thank you to everyone who commented on this issue!  I highly appreciated the 
> views expressed, and believe that they greatly improved the end outcome of 
> this change.  Again, if you still strongly oppose this change or I am 
> forgetting something important, let me know before Thursday evening!
> Leif Rasmussen
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

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

Re: [Talk-GB] Android Auto and OSM

[Marc Gemis]

I contacted MagicEarth (which uses OSM as well) a couple of days ago
about this topic.
They confirmed that there is no API and gave me a workaround to use
MagicEarth on the smartphone screen and Android Auto on the screen of
the car. They are looking forward to supper Android Auto when it
becomes possible.

Since Apple just opened CarPlay to other map providers with iOS12, one
can only hope Google will follow.

m.
On Mon, Sep 24, 2018 at 1:55 AM Simon Poole  wrote:
>
> The question is what not "ignoring this" entails.
>
> Essentially we would need to file a complaint with the respective authorities 
> which afaik even the companies that are directly affected by this (see for 
> example 
> https://forum.xda-developers.com/android-auto/android-auto-general/maps-android-auto-t3339439)
>  have not done.
>
> As we don't have a direct business interests in this (as in no revenue from 
> such business), the OSMF would have to team up with market players that are 
> actually affected by the situation. All possible, but rather unlikely to 
> actually happen, not to mention that any result from such an action would be 
> way down the road substantially after the exit plans of any likely commercial 
> partner.
>
> Simon
>
> Am 24. September 2018 00:05:20 MESZ schrieb Rob Nickerson 
> :
>>
>> Hi Simon,
>>
>> No this is not that simple and (in my view) OSM shouldn't ignore this. It 
>> works with quite a few existing third party apps (list on [1], [2]) 
>> including Google competitors (e.g. Amazon Music) and Open Source (e.g. 
>> Signal messenger).
>>
>> I cannot see any OSM app in the list which is a shame as we could loose 
>> audience as a result.
>>
>> P.S. The car also had Apple's equivalent (Apple CarPlay) but I couldn't test 
>> this as I don't have an iOS device.
>>
>> P.P.S According to google: Automobile manufacturers that will offer Android 
>> Auto support in their cars include Abarth, Acura, Alfa Romeo, Audi, Bentley, 
>> Buick, Cadillac, Chevrolet, Chrysler, Dodge, Fiat, Ford, GMC, Honda, 
>> Hyundai, Infiniti, Jaguar Land Rover, Jeep, Kia, Lamborghini, Lexus, 
>> Lincoln, Mahindra and Mahindra, Maserati, Mazda, Mercedes-Benz, Mitsubishi, 
>> Nissan, Opel, Peugeot, RAM, Renault, SEAT, Škoda, SsangYong, Subaru, Suzuki, 
>> Tata Motors Cars, Volkswagen and Volvo.
>>
>> [1] https://www.android.com/auto/
>> [2] 
>> https://play.google.com/store/apps/collection/promotion_3001303_android_auto_all
>>
>> Thanks,
>>
>> Rob
>
>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail 
> gesendet.
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

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