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&go 
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&go 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&go 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] Talk-be Digest, Vol 143, Issue 5

[Jakka]

@ pilippe
satelliet beelden zullen nooit juist zijn, hangt af welke versie je 
gebruikt en is dus altijd een beetje schipperen met AIV/GRB toestanden.

Ik heb mijne lintmeter niet bij ;)
Vermoed ook een verschil tussen ID en josm calibreringvan de layers...


Op 4/11/2019 om 18:10 schreef Philippe Casteleyn:

Ik had eerder kritiek verwacht omdat de parkeerlijnen van Jakka niet op
die van de satellietfoto vallen.  Misschien is de satellietfoto verschoven.

Mijn parking lot draagt de gevolgen.  Het is wellicht ook niet zo
verstandig de vier buitenhoeken te nemen als zone, maar kan het anders
in ID ?

Ik zal maar stoppen met parkings.  Waar is er eentje volledig en juist
getekend ?

Ik had gezien dat Anakil gehandicapten getekend heeft.  Ik heb er niet
op gelet dat ik bovenop hem bezig was.



De gebouwen zijn trouwens ook niet volgens het GRB getekend.



Ik ben nu al zaken aan het tekenen waarvoor geen tag bestaat, zoals een
haventje voor modelboten.











___
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] Talk-be Digest, Vol 143, Issue 5

[Philippe Casteleyn]

Ik had eerder kritiek verwacht omdat de parkeerlijnen van Jakka niet op die van 
de satellietfoto vallen.  Misschien is de satellietfoto verschoven.
Mijn parking lot draagt de gevolgen.  Het is wellicht ook niet zo verstandig de 
vier buitenhoeken te nemen als zone, maar kan het anders in ID ?
Ik zal maar stoppen met parkings.  Waar is er eentje volledig en juist getekend 
?
Ik had gezien dat Anakil gehandicapten getekend heeft.  Ik heb er niet op gelet 
dat ik bovenop hem bezig was.

De gebouwen zijn trouwens ook niet volgens het GRB getekend.

Ik ben nu al zaken aan het tekenen waarvoor geen tag bestaat, zoals een 
haventje voor modelboten.




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

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 pro