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 ?

[Stijn Rombauts via Talk-be]

 Beste s8evq

En heb je ondertussen al leren lezen?"This page shows issues on elements that 
were last modified by 'StijnRR'. This doesn't means that this user is 
responsible for all these issues."
Als wat ik gedaan heb, 'not done' is. Wat is jouw valselijke beschuldiging dan?
Je hebt al snel meer dan 500 issues op je naam als je al wat editeerjaren 
achter de rug hebt. Er zitten inderdaad nog massa's fouten in OSM (als je alles 
waar osmose over klaagt al fouten kan noemen). Ik heb er al veel opgelost. Soms 
ben ik zelfs verplicht om ze op te lossen omdat JOSM anders weigert te 
uploaden. Maar ik kan onmogelijk alles overal rechttrekken. Daarvoor is mijn 
leven te kort. Ik maak zelf ongetwijfeld ook fouten, maar de verhouding 
edits/fouten ligt bij een aantal mappers redelijk scheef. Terwijl er genoeg 
andere mappers zijn die bewijzen dat het anders kan.En het aankaarten van 
(andermans) fouten op deze mailinglist kan nuttig zijn voor iedereen. We kunnen 
allemaal nog wel iets van elkaar en van elkaars fouten leren. En ik zou hier 
alles kunnen anonimiseren, maar iedereen kan toch in osm terugvinden wie wat 
gedaan heeft.
Een aansluitend vraagje: heeft het nog zin om iemand te wijzen op fouten die 2, 
3, 4, ... jaren geleden zijn gemaakt? Wat doen jullie?

StijnRR


Op maandag 4 november 2019 19:27:10 CET schreef s8evq :  
 
 Dag Stijn,

Wie zonder zonde is werpe de eerste steen:
http://osmose.openstreetmap.fr/en/byuser/StijnRR
Number of found issues: more than 500

Ik vind het not done om iemand zijn edits te dissecteren op een publieke 
mailinglist.

On Mon, 4 Nov 2019 15:31:34 + (UTC), 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
  ___
Talk-be mailing list
Talk-be@openstreetmap.org

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] Overdreven gedetailleerde mapping ? Exaggerated detailed mapping?

[marc marc]

If it'sn't a place=locality, but only a cadastral name with known 
boundary, a boundary=cadastral + name is better
the problem is that it is often places said that the elders used
without precise limits and it is then taken up by the land registry
and notaries, for example to locate a famrland

Le 09.11.19 à 11:45, Karel Adams a écrit :
> Mij lijkt dit enkel een kwestie van "minder-dan-perfecte" tagging: in 
> plaats van "name=HoutchiPloutch" hoort het voor mij te zijn 
> "name:land_register=..." of iets dergelijks.De tag "place=locality" 
> lijkt mij trouwens ook aanvechtbaar.
> 
> A mon avis, il suffit d'appliquer un tag plus correcte ou plus 
> approprié, p.e. "name:land_register" au lieu de "name:". Je ne suis pas 
> trop heureux avec le "place=locality" non plus.
> 
> KA
> 
> On 11/8/19 9:59 PM, EeBie wrote:
>> I have a problem with a kind of exaggerated detailed mapping that 
>> makes the map difficult to read and use.
>> That is by giving fields and meadows their cadastral name by mapping 
>> them as place=locality and name=*.
>> You can find this in some parts of Wallonie as 
>> https://www.openstreetmap.org/#map=16/50.5175/5.4718
>> When using an OSM map, these fields look similar to villages. It 
>> happened that I couldn't find the name of a village between a lot of 
>> such names of  fields and meadows.
>> Unfortunately it is even more used in France: try to find the villages 
>> in this: https://www.openstreetmap.org/#map=13/49.2093/5.3281=C
>> I hope that it will not end like this in Wallonie nor Flandres. I 
>> guess nobody is waiting to see all the cadastral names on an OSM maps. 
>> That is for dedicated cadastral maps.
>>
>> Eebie
>>
>>
>>
>> Op 5/11/19 om 09:26 schreef Lionel Giard:
>>> @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.
>>>
>>> On Mon, Nov 4, 2019 at 4:33 PM Stijn Rombauts via Talk-be
>>> mailto:talk-be@openstreetmap.org>> 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 

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

[Karel Adams]

Mij lijkt dit enkel een kwestie van "minder-dan-perfecte" tagging: in 
plaats van "name=HoutchiPloutch" hoort het voor mij te zijn 
"name:land_register=..." of iets dergelijks.De tag "place=locality" 
lijkt mij trouwens ook aanvechtbaar.


A mon avis, il suffit d'appliquer un tag plus correcte ou plus 
approprié, p.e. "name:land_register" au lieu de "name:". Je ne suis pas 
trop heureux avec le "place=locality" non plus.


KA

On 11/8/19 9:59 PM, EeBie wrote:
I have a problem with a kind of exaggerated detailed mapping that 
makes the map difficult to read and use.
That is by giving fields and meadows their cadastral name by mapping 
them as place=locality and name=*.
You can find this in some parts of Wallonie as 
https://www.openstreetmap.org/#map=16/50.5175/5.4718
When using an OSM map, these fields look similar to villages. It 
happened that I couldn't find the name of a village between a lot of 
such names of  fields and meadows.
Unfortunately it is even more used in France: try to find the villages 
in this: https://www.openstreetmap.org/#map=13/49.2093/5.3281=C
I hope that it will not end like this in Wallonie nor Flandres. I 
guess nobody is waiting to see all the cadastral names on an OSM maps. 
That is for dedicated cadastral maps.


Eebie



Op 5/11/19 om 09:26 schreef Lionel Giard:
@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.

On Mon, Nov 4, 2019 at 4:33 PM Stijn Rombauts via Talk-be
mailto:talk-be@openstreetmap.org>> 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

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

[Chris Van Bael]

Hi Eebie,

you have a point that indeed those maps are confusing the way OSM renders
them at the site.
But with mapping: there is a difference between what is in the database and
what is displayed.
If what you see is not clear, then perhaps the renderer should be adapted.

As I said in an earlier post: the first line on the OSM wiki states it
wants user to use maps "using them in creative, productive, or unexpected
ways"
If you only put in data for foot/bike/car navigation, you are excluding a
whole range of create and unexpected usages.
So it all boils down to what exactly OSM wants to be.

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.

So I would say: let's provide sufficient data to allow other uses of OSM.
If that includes cadaster data, why not?  It's not like all cadaster are
free or easy to use.
If local people are willing to put the effort into inserting correct data,
why not allow them?
It is their map also.

On Fri, 8 Nov 2019 at 23:00, EeBie  wrote:

> I have a problem with a kind of exaggerated detailed mapping that makes
> the map difficult to read and use.
> That is by giving fields and meadows their cadastral name by mapping them
> as place=locality and name=*.
> You can find this in some parts of Wallonie as
> https://www.openstreetmap.org/#map=16/50.5175/5.4718
> When using an OSM map, these fields look similar to villages. It happened
> that I couldn't find the name of a village between a lot of such names of
> fields and meadows.
> Unfortunately it is even more used in France: try to find the villages in
> this: https://www.openstreetmap.org/#map=13/49.2093/5.3281=C
> I hope that it will not end like this in Wallonie nor Flandres. I guess
> nobody is waiting to see all the cadastral names on an OSM maps. That is
> for dedicated cadastral maps.
>
> Eebie
>
>
>
> Op 5/11/19 om 09:26 schreef Lionel Giard:
>
> @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.
>>
>> 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 

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

[EeBie]

I have a problem with a kind of exaggerated detailed mapping that makes 
the map difficult to read and use.
That is by giving fields and meadows their cadastral name by mapping 
them as place=locality and name=*.
You can find this in some parts of Wallonie as 
https://www.openstreetmap.org/#map=16/50.5175/5.4718
When using an OSM map, these fields look similar to villages. It 
happened that I couldn't find the name of a village between a lot of 
such names of  fields and meadows.
Unfortunately it is even more used in France: try to find the villages 
in this: https://www.openstreetmap.org/#map=13/49.2093/5.3281=C
I hope that it will not end like this in Wallonie nor Flandres. I guess 
nobody is waiting to see all the cadastral names on an OSM maps. That is 
for dedicated cadastral maps.


Eebie



Op 5/11/19 om 09:26 schreef Lionel Giard:
@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.

On Mon, Nov 4, 2019 at 4:33 PM Stijn Rombauts via Talk-be
mailto:talk-be@openstreetmap.org>> 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
mailto:marc.ge...@gmail.com>>:
>
>
> > 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 

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

[Lionel Giard]

@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.
>
> 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 <
> marc.ge...@gmail.com>:
> >
> >
> > > 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
>
___
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 ?

[Jakka]

@Pieter,

neem eens persoonlijk contact met mij betreffende "real-time shop 
parking"


Op 4/11/2019 om 21:28 schreef Pieter Colpaert:

Dag allen,

Eerst en vooral: merci voor de contributies aan OSM, desondanks de
kleine meningsverschillen ;-)

For what it’s worth:

Het mappen van meer detail vind ikzelf enorm waardevol: het geeft net
dat ietsje meer waardoor ook overheden gaan kijken naar wat er op
OpenStreetMap te vinden is, want dat kan mogelijks net dat beetje meer
gedetailleerd zijn dan hun eigen inventarisatie van het openbaar domein.

Verder zijn bijvoorbeeld de data over de real-time shop parking
beschikbaarheid in Kortrijk als open data. Zou tof zijn om op termijn
ook OSM’s individuele parkingplaatsen te kunnen linken aan de real-time
locatie, zoals nu sommige zaken al gelinkt zijn een wikidata.

Groeten,

Pieter

On 04/11/2019 19.26, s8evq wrote:

Dag Stijn,

Wie zonder zonde is werpe de eerste steen:
http://osmose.openstreetmap.fr/en/byuser/StijnRR
Number of found issues: more than 500

Ik vind het not done om iemand zijn edits te dissecteren op een
publieke mailinglist.

On Mon, 4 Nov 2019 15:31:34 + (UTC), 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



___
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 ?

[Pieter Colpaert]

Dag allen,

Eerst en vooral: merci voor de contributies aan OSM, desondanks de 
kleine meningsverschillen ;-)


For what it’s worth:

Het mappen van meer detail vind ikzelf enorm waardevol: het geeft net 
dat ietsje meer waardoor ook overheden gaan kijken naar wat er op 
OpenStreetMap te vinden is, want dat kan mogelijks net dat beetje meer 
gedetailleerd zijn dan hun eigen inventarisatie van het openbaar domein.


Verder zijn bijvoorbeeld de data over de real-time shop parking 
beschikbaarheid in Kortrijk als open data. Zou tof zijn om op termijn 
ook OSM’s individuele parkingplaatsen te kunnen linken aan de real-time 
locatie, zoals nu sommige zaken al gelinkt zijn een wikidata.


Groeten,

Pieter

On 04/11/2019 19.26, s8evq wrote:

Dag Stijn,

Wie zonder zonde is werpe de eerste steen:
http://osmose.openstreetmap.fr/en/byuser/StijnRR
Number of found issues: more than 500

Ik vind het not done om iemand zijn edits te dissecteren op een publieke 
mailinglist.

On Mon, 4 Nov 2019 15:31:34 + (UTC), 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



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

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

[s8evq]

Dag Stijn,

Wie zonder zonde is werpe de eerste steen:
http://osmose.openstreetmap.fr/en/byuser/StijnRR
Number of found issues: more than 500

Ik vind het not done om iemand zijn edits te dissecteren op een publieke 
mailinglist.

On Mon, 4 Nov 2019 15:31:34 + (UTC), 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 ?

[Jakka]

@ StijnRR

< Maar waarom een aantal wel en de andere niet? Is na een tijdje 
vervelend  moet ook nog een beetje overlaten aan anderen ;)


< foutief gemapt met amenity= parking deze begrijp ik niet typ fout 
of totaal geen parking?


< 3 brede parkeerplaatsen  getekend terwijl het er 5 smalle zijn, klopt 
mogelijk laten misleiden door schaduw...


sputterde niet tegen anders zou ik het gemerkt hebben. Was daar een 
grote aanpassing van kruispunt die blijkbaar niemand wou bijwerken


interpretatie te ruim hindernissen, toestellen, toestanden om verkeer te 
leiden veilig te laten verlopen en niet de letterlijke vertaling 
"verkeer vertragen"


< aantal fietspaden zijn apart bijgetekend...De oneway-tag lijkt mij ook 
een aantal keer te ontbreken  geen mapillary beelden die wel oneway 
tag bevestigden


Jammer dat je me daar niet onmiddellijk van op de hoogte bracht

Op 4/11/2019 om 16:31 schreef Stijn Rombauts via Talk-be:

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 ?

[Jasper Michels]

Laten we anders een #metoo-openstreetmap creëren op twitter. Laat jullie
daar maar gaan.

Ik kom de naam jakka heel veel tegen bij edits. Dan is het toch ook logisch
dat er hier en daar iets voor verbetering vatbaar is. Wie niets doet, niets
mis doet, maar dan heb je ook geen community meer.

Wat niet wegneemt dat fouten gerust mogen gemeld worden aan de persoon zelf.

Dus:
Allen naar twitter. User kbentekik #metoo-openstreetmap
Niet veel edits, wellicht veel fouten.
I love vuilbakken mappen

Dit bedoelt als grapje, waarbij ik alle partijen wel snap. Maar aub niet op
de man spelen.

Kbentekik


On Mon, 4 Nov 2019, 16:33 Stijn Rombauts via Talk-be, <
talk-be@openstreetmap.org> 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 <
> marc.ge...@gmail.com>:
>
>
> > 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 ?

[Stijn Rombauts via Talk-be]

 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

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

[wannesss]

Off topic: doet me eraan denken dat ik de door Bpost geschrapte brievenbussen 
in de buurt eens moet updaten.

On-topic: ieder mapt wat hij wil, en wat hij zelf belangrijk vindt. Hoe 
pietluttig het ook is, hoe onvolletde rest van de omgeving ook is.
 Iemand zn CORRECTE edits verwijderen omdat je ze overbodig vind is not done. 

> Op 4 nov. 2019 om 13:08 heeft Marc Gemis  het volgende 
> geschreven:
> 
> 
>> 
>> 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

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 ?

[Tim Couwelier]

Toch ook even mijn 'two cents' ertussen gooien.

Ik begrijp de sceptische insteek: moet je zo'n details gaan mappen, terwijl
er nog zoveel meer is wat ontbreekt?.
In geval van een BETAALDE dienstverlening, ben ik het er 100% mee eens dat
het een rommeltje is als je zo te werk gaat, 'resultaatgericht' is dat niet.

Maar dat is het hier niet. Het is een database (en dus meer dan gewoon een
kaart), wat een rommelig datamodel heeft maar waar zeer veel in terecht kan.
En als iemand dat leuk vindt om daar bomen in te mikken, of brievenbussen,
of verlichtingspalen .. dat ie lekker doet. Tuurlijk is dat een beetje
micromappen. Maar ik heb nu eenmaal meer met het groen op mijn wijk, dan
met de verlichtingspalen in Antwerpen.

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.



Op ma 4 nov. 2019 om 10:33 schreef Marc Gemis :

> Chris,
>
> je hoeft niet bang te zijn om je mening te geven. Alvast bedankt
> ervoor, goed dat je die quote ivm innovatie aanhaalt.
>
> Je kan de capaciteit van een parking ook taggen via de "capacity" tag
> op amenity=parking. Dat zou een een plaatsbesparende (?) mogelijkheid
> zijn.
> Maar was er onlangs niet ergens de vraag hoeveel vierkante meter er
> aan parking gespendeerd wordt ? Daarvoor heb je meer aan parking
> spaces (als je onderscheid wil maken tussen staanplaatsen en wegen
> ertussen).
>
> Voor bloembakken e.d. denk ik ook weer aan navigatie voor
> slechtzienden, of zelfs rolsstoelgebruikers (tenminste als we de
> voetpaden ook als vlakken zouden tekenen), zodat men nog weet hoeveel
> (of hoe weinig) plaats er is tussen muur en bloembak.
> Ook voor het bepalen van oversteekplaatsen voor voetgangers in het
> algemeen geeft het mappen van grasperken e.d. aan waar er hindernissen
> zijn.
>
> maar we staren ons inderdaad soms blind op data voor de navigatie van
> auto's en in iets mindere mate van fietser en voetgangers zonder enige
> vorm van beperking.
>
> mvg
>
> m.
>
> On Mon, Nov 4, 2019 at 9:44 AM Chris Van Bael 
> wrote:
> >
> > Hallo,
> >
> > long-time lezer hier, af en toe wat bijgedragen, maar vooral OSM
> gebruikt. Dus als jullie mijn commentaar niet belangrijk vinden, ook goed.
> >
> > Om even in te haken op wat wel of niet mappen. Op de OSM wiki staat: "
> The project aims to promote new and interesting uses of this data"
> > Als je geen parkeerplaatsen of zelfs bloemperkjes mapt, dan ga je in
> ieder geval daar nooit een nieuw of interessant gebruik voor krijgen.
> > Zeker voor parkeerplaatsen zie ik al verschillende mogelijkheden:
> > - voor winkels, overheid en andere organisaties nagaan hoeveel
> parkeerplaatsen er zijn in een regio om aan de hand daarvan bepaalde
> beslissingen te nemen.
> > - voor (semi) autonome auto's om te weten of men hier kan parkeren of
> wat de kans is dat er een vrije parkeerplaats is
> > Zelf kan ik niets bedenken voor bloemperkjes, maar misschien een
> milieudeskundige wel? (afstand tussen bloemperken om levensvatbaarheid van
> bijen te onderzoeken?)
> > Ik zou dus zeker niet zeggen om iets niet te mappen omdat we er nu geen
> applicatie voor kunnen bedenken.
> >
> > Waarom zou je iets niet willen mappen?
> > - onderhoud: dit vind ik nog de belangrijkste reden om iets niet te
> mappen: mogelijk heb je liever een kleinere, maar correcte database, dan
> een uitgebreide, maar onbetrouwbare database. Hierover vind ik echter niets
> terug op OSM.
> > - opslag: meer data neemt natuurlijk meer ruimte in, maar we spreken
> hier niet over foto's of films.
> > - performantie: meer nodes kunnen queries vertragen. Maar voor we data
> input gaan beperken, zou er dan eerst naar de queries gekeken moeten worden
> of die juist gemaakt zijn.  Zelfs als die dat zijn, kan je het misschien
> oplossen door er meer hardware tegenaan te gooien. Kost geld? Wel, dan moet
> OSM misschien meer geld zien op te halen ipv de data te beperken.  Ik lees
> nergens op OSM dat men enkel een routeplanner wil zijn.
> >
> > Ivm junk: ik denk dat dat minder speelt dan bij Wikipedia omdat het toch
> wat moeilijker is om een aanpassing te maken en deze ook minder zichtbaar
> is.
> > Maar: het is niet omdat er geen goede procedure is om met junk om te
> gaan, dat men dan maar minder moet gaan mappen.
> >
> > Bedankt om dit te lezen,
> >
> > Chris
> >
> >
> >
> > On Sun, 3 Nov 2019 at 20:04, 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
> 

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

[Marc Gemis]

Chris,

je hoeft niet bang te zijn om je mening te geven. Alvast bedankt
ervoor, goed dat je die quote ivm innovatie aanhaalt.

Je kan de capaciteit van een parking ook taggen via de "capacity" tag
op amenity=parking. Dat zou een een plaatsbesparende (?) mogelijkheid
zijn.
Maar was er onlangs niet ergens de vraag hoeveel vierkante meter er
aan parking gespendeerd wordt ? Daarvoor heb je meer aan parking
spaces (als je onderscheid wil maken tussen staanplaatsen en wegen
ertussen).

Voor bloembakken e.d. denk ik ook weer aan navigatie voor
slechtzienden, of zelfs rolsstoelgebruikers (tenminste als we de
voetpaden ook als vlakken zouden tekenen), zodat men nog weet hoeveel
(of hoe weinig) plaats er is tussen muur en bloembak.
Ook voor het bepalen van oversteekplaatsen voor voetgangers in het
algemeen geeft het mappen van grasperken e.d. aan waar er hindernissen
zijn.

maar we staren ons inderdaad soms blind op data voor de navigatie van
auto's en in iets mindere mate van fietser en voetgangers zonder enige
vorm van beperking.

mvg

m.

On Mon, Nov 4, 2019 at 9:44 AM Chris Van Bael  wrote:
>
> Hallo,
>
> long-time lezer hier, af en toe wat bijgedragen, maar vooral OSM gebruikt. 
> Dus als jullie mijn commentaar niet belangrijk vinden, ook goed.
>
> Om even in te haken op wat wel of niet mappen. Op de OSM wiki staat: " The 
> project aims to promote new and interesting uses of this data"
> Als je geen parkeerplaatsen of zelfs bloemperkjes mapt, dan ga je in ieder 
> geval daar nooit een nieuw of interessant gebruik voor krijgen.
> Zeker voor parkeerplaatsen zie ik al verschillende mogelijkheden:
> - voor winkels, overheid en andere organisaties nagaan hoeveel 
> parkeerplaatsen er zijn in een regio om aan de hand daarvan bepaalde 
> beslissingen te nemen.
> - voor (semi) autonome auto's om te weten of men hier kan parkeren of wat de 
> kans is dat er een vrije parkeerplaats is
> Zelf kan ik niets bedenken voor bloemperkjes, maar misschien een 
> milieudeskundige wel? (afstand tussen bloemperken om levensvatbaarheid van 
> bijen te onderzoeken?)
> Ik zou dus zeker niet zeggen om iets niet te mappen omdat we er nu geen 
> applicatie voor kunnen bedenken.
>
> Waarom zou je iets niet willen mappen?
> - onderhoud: dit vind ik nog de belangrijkste reden om iets niet te mappen: 
> mogelijk heb je liever een kleinere, maar correcte database, dan een 
> uitgebreide, maar onbetrouwbare database. Hierover vind ik echter niets terug 
> op OSM.
> - opslag: meer data neemt natuurlijk meer ruimte in, maar we spreken hier 
> niet over foto's of films.
> - performantie: meer nodes kunnen queries vertragen. Maar voor we data input 
> gaan beperken, zou er dan eerst naar de queries gekeken moeten worden of die 
> juist gemaakt zijn.  Zelfs als die dat zijn, kan je het misschien oplossen 
> door er meer hardware tegenaan te gooien. Kost geld? Wel, dan moet OSM 
> misschien meer geld zien op te halen ipv de data te beperken.  Ik lees 
> nergens op OSM dat men enkel een routeplanner wil zijn.
>
> Ivm junk: ik denk dat dat minder speelt dan bij Wikipedia omdat het toch wat 
> moeilijker is om een aanpassing te maken en deze ook minder zichtbaar is.
> Maar: het is niet omdat er geen goede procedure is om met junk om te gaan, 
> dat men dan maar minder moet gaan mappen.
>
> Bedankt om dit te lezen,
>
> Chris
>
>
>
> On Sun, 3 Nov 2019 at 20:04, 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 

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

[Chris Van Bael]

Hallo,

long-time lezer hier, af en toe wat bijgedragen, maar vooral OSM gebruikt.
Dus als jullie mijn commentaar niet belangrijk vinden, ook goed.

Om even in te haken op wat wel of niet mappen. Op de OSM wiki staat: " The
project aims to promote new and interesting uses of this data"
Als je geen parkeerplaatsen of zelfs bloemperkjes mapt, dan ga je in ieder
geval daar nooit een nieuw of interessant gebruik voor krijgen.
Zeker voor parkeerplaatsen zie ik al verschillende mogelijkheden:
- voor winkels, overheid en andere organisaties nagaan hoeveel
parkeerplaatsen er zijn in een regio om aan de hand daarvan bepaalde
beslissingen te nemen.
- voor (semi) autonome auto's om te weten of men hier kan parkeren of wat
de kans is dat er een vrije parkeerplaats is
Zelf kan ik niets bedenken voor bloemperkjes, maar misschien een
milieudeskundige wel? (afstand tussen bloemperken om levensvatbaarheid van
bijen te onderzoeken?)
Ik zou dus zeker niet zeggen om iets niet te mappen omdat we er nu geen
applicatie voor kunnen bedenken.

Waarom zou je iets niet willen mappen?
- onderhoud: dit vind ik nog de belangrijkste reden om iets niet te mappen:
mogelijk heb je liever een kleinere, maar correcte database, dan een
uitgebreide, maar onbetrouwbare database. Hierover vind ik echter niets
terug op OSM.
- opslag: meer data neemt natuurlijk meer ruimte in, maar we spreken hier
niet over foto's of films.
- performantie: meer nodes kunnen queries vertragen. Maar voor we data
input gaan beperken, zou er dan eerst naar de queries gekeken moeten worden
of die juist gemaakt zijn.  Zelfs als die dat zijn, kan je het misschien
oplossen door er meer hardware tegenaan te gooien. Kost geld? Wel, dan moet
OSM misschien meer geld zien op te halen ipv de data te beperken.  Ik lees
nergens op OSM dat men enkel een routeplanner wil zijn.

Ivm junk: ik denk dat dat minder speelt dan bij Wikipedia omdat het toch
wat moeilijker is om een aanpassing te maken en deze ook minder zichtbaar
is.
Maar: het is niet omdat er geen goede procedure is om met junk om te gaan,
dat men dan maar minder moet gaan mappen.

Bedankt om dit te lezen,

Chris



On Sun, 3 Nov 2019 at 20:04, 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
> > 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 

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
> > 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 

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

[Karel Adams]

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
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

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

[Marc Gemis]

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

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

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

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

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

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

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

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

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

[Jakka]

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

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

[Karel Adams]

Daarmee ga ik stevig akkoord, Denis. Ook graag akkoord dat een 
gehandicaptenparkeerplaats er wel mag uitspringen, maar dat doet de 
renderer dan weer niet, of toch niet op duidelijke wijze. Natuurlijk 
moeten we niet mappen voor de renderer, maar zo lijkt het inderdaad 
nergens op. Af en toe lijkt het me trouwens dat er, inzake 
detailpuntjes, nogal geknutseld wordt aan die renderer.



Toch een waarschuwing: een maand of twee geleden had iemand iets 
gelijkaardigs gedaan, op een vliegveld in Verweggistan individuele 
bloemperkjes en struiken gemapt en zo. Ik heb dat toen een beetje 
opgekuist, waarop die mapper me prompt heeft "aangeklaagd" bij de hogere 
autoriteit ("data working group") en die heeft hem prompt gelijk 
gegeven, en mij een stevige uitbrander. Dat is toen een beetje uit de 
hand gelopen tussen mij en die hogere autoriteit, ik heb nu mijn 
bijdragen opgeschort tot er enig teken van toenadering komt... Uit dat 
dispuut heb ik onthouden dat die data working group het belangrijk vindt 
om niets te corrigeren zonder eerst met de betreffende mapper te 
communiceren (wat ik ergens wel redelijk vind, maar manifeste fouten 
zijn volgens mij toch manifeste fouten) en ook dat men voorrang geeft 
aan inbreng van plaatselijke mappers, zonder zich zelfs af te vragen hoe 
technisch correct die inbreng dan wel moge zijn. En daarmee heb ik het 
al lastiger...



Vr.gr.,



On 11/2/19 1:37 PM, Denis Verheyden wrote:

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
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[OSM-talk-be] Overdreven gedetailleerde mapping ?

[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/assets/osm_logo_256-4b5bd6b572394388f0c1bef4ad9772d03dc4f76d8944b6beffc39286071a62d7.png]
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