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 <chris.van.b...@gmail.com> 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 <fa348...@skynet.be> 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. 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 <vdmfrank...@gmail.com> wrote:
>> >> Op 2/11/2019 om 14:37 schreef Denis Verheyden:
>> >>> Dag allen,
>> >>>
>> >>> Na een tijdje inactiviteit ben ik opnieuw wat verbeteringen op OSM aan
>> >>> het aanbrengen (kleine stukjes GRB-import, aanvullen of verbeteren
>> >>> huidige situaties).
>> >>> Echter kwam ik onlangs een geval tegen dat mijns inziens overdreven
>> >>> gedetailleerde mapping is:
>> >>>
>> >>> https://www.openstreetmap.org/#map=19/50.99435/4.47499
>> >>>
>> >>> <https://www.openstreetmap.org/#map=19/50.99435/4.47499>
>> >>>
>> >>> OpenStreetMap <https://www.openstreetmap.org/#map=19/50.99435/4.47499>
>> >>> OpenStreetMap is a map of the world, created by people like you and free
>> >>> to use under an open license. Hosting is supported by UCL, Bytemark
>> >>> Hosting, and other partners.. Learn More Start Mapping
>> >>> www.openstreetmap.org
>> >>>
>> >>> Ik heb het hier vooral over de individuele parkeerplaatsen bij die
>> >>> winkels, ingetekend door Jakka (hopelijk dezelfde als die van de mailing
>> >>> list hier ?).
>> >>> Ik bedoel: dit is gewoon kaartvervuiling, zet daar gewoon 1 area met
>> >>> amenity=parking en de kous is af.
>> >>>
>> >>> Plaatsen voor gehandicapten/PRM zou ik nog wel toelaten afzonderlijk in
>> >>> te tekenen, ook al omdat het anders moeilijk in een area te definiëren
>> >>> is waar men dan een tag "capacity:disabled" op zet. Dan weet je wel
>> >>> hoevéél er zijn, maar je weet niet wáár ze zich bevinden.
>> >>>
>> >>> Een zelfde opmerking aan de fetishisten die graag afzonderlijke bomen
>> >>> intekenen: stop er aub mee. Tenzij het echt een karakteristiek kenmerk
>> >>> is of een echte bomenrij staat ("Allee unter den Linden" in Berlijn om
>> >>> maar te zeggen), maar laat het anders gewoon zo. Er zijn betere zaken te
>> >>> mappen.
>> >>>
>> >>> Groeten,
>> >>>
>> >>> Denis
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>
> _______________________________________________
> 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
