Naar aanleiding van een recente terechte BAG-import opmerking van FrankOverman en mijn reactie daarop: “ Erg vreemd de gebouwen 1, 2 & 3 horen precies op het groene veld te vallen wat ook in het echt zo is want de gebouwen zijn casco af in het echt… Via de bagviewerlinks die ik eerder gestuurd heb is dat ook duidelijk te zien… en heb ook express de bagviewerlinks gebruikt omdat alleen al gebouw 1 133 adressen bevat…
Dit document van gemeente Haarlem geeft echter uitsluitsel hoe het gaat worden: https://gemeentebestuur.haarlem.nl/bestuurlijke-stukken/609866-Noordvariant-als-voorkeursvariant-mobiliteitshub-4.pdf
Ik zal persoonlijk de OSM-kaart aanpassen als alles precies volgens bovenstaande pdf gebouwd is… alles is zo recent dat er nu in deze bouwfase een schijnbare verwarrende OSM kaart ontstaat, maar het komt goed…”
Mijn vraag: is er een manier om een link zoals hierboven aangegeven in de OSM kaart te verwerken zonder dat dit (te veel) rendercapaciteit gaat vergen ?
De reden dat ik een link zoals boven graag in een object wil verwerken is dat niet iedereen die edits doet op OSM ook daadwerkelijk lid is van het forum, laat staan ook actief post en/of onderwerpen leest op dit forum. De kans dat een niet forum lid naar aanleiding van bovenstaand voorbeeld een object (met louter goede bedoelingen laat dat duidelijk zijn om de kaart te ‘verbeteren’) verwijderd omdat hij of zij met de ogen ziet dat de weg in dit voorbeeld zeker nog bestaat en dus het gebouw als fantoomgebouw ziet. Dit terwijl als deze OSM editor meer achtergrond kan lezen/bekijken middels een link met achtergrond info meteen weet dat een object onderdeel is van veel veranderingen in de omgeving.
Doel is verder om scheiding te kunnen maken tussen: OSM-“vandalisten” en betrokken OSM-mappers met lokale kennis.
Vraag: hoe gaat OSM kwa rendering om met het veld: OMSCHRIJVING ?
Als dit veld geen capaciteits effect heeft op OSM: is het dan mogelijk een veld te maken: NABIJE TOEKOMST of anders (misschien nog betere oplossing) een speciaal TOEKOMST-OPMERKING veld.
Graag jullie reaktie/ideeën en/of opmerkingen hierover.
Qua rendering gebeurt er (gelukkig) niets met de tag omschrijving (description); wat je kunt doen is op het pand dat het betreft aan tag note of fixme toevoegen en een link naar de website die je wilt en eventueel andere tekst. Een zorgvuldige mapper leest deze notes (als ie de tijd neemt) en handelt daarnaar.
Ik wilde juist NIET de fixme tag gebruiken want dat impliceert nl. dat er iets fout zou zijn om te fixen terwijl er niets te fixen is…
Bovendien vervuilt het de ‘ECHTE’ fix me gevallen en werkt daardoor minder productief voor de echte fixme gevallen…
Het omschrijvingsveld heb ik als experiment incidenteel al eens gebruikt maar ‘vervuilt’ echte omschrijvingsteksten die behoren bij een object anders dan eigenlijk een periodieke opmerking die uitleg geeft wat een OSM-mapper op een moment ziet.
Bij een TOEKOMST-OPMERKING veld zou het fijn zijn als je daar ook een geldigheidstijd indicatie bij zou kunnen zetten… Zo van: na overschrijding van bijvoorbeeld 3 weken na tijdsaanduiding via een maproulette scriptje deze laten tonen ter beoordeling of objecten daadwerkelijk verwijderd mogen worden…
Zo maar wat out of the box meedenk gedachten die door andere meer ervaren OSM-ers weer kunnen leiden tot NOG perfectere oplossingen…
Specifiek op Nederland gericht de description:nl tag (2200 gebruikt). Men kan ook note:nl gebruiken (slechts 260 keer volgens TagInfo) hetwelk voor mapper in het bijzonder is.
Ik doe vaker note=FIXME: text. De FIXME is opzoekbaar maar veroorzaakt geen alarmeringen. In KeepRight worden ze ook van een vlaggetje voorzien voor als iemand er in het bijzonder naar opzoek is.
Over geldigheids tijd, er zijn date tags die bijv in StreetComplete verschijnen als de datum gepasseerd is. Zeker gebruik ik vaker check_date=yyyy-mm-dd als iets geupdate wordt. Dan komt de vraag in SC “is het er nog?” na verloop van tijd.
Ik gebruik vaak de note tag. Of ik zet wel eens wat in de omschrijving van de wijzigingsset zelf. Zoals “let op, pdok/luchtfoto/bgt/whatever is niet actueel, wijzigingen zijn gecontroleerd in het veld”.
Fixme tag gebruik ik alleen als er wat te fixxen valt. Bijvoorbeeld een wandelpad dat ik maar deels heb ingemeten. Of Specifieke details die ik op moment van verwerken niet weet maar iemand anders in de toekomst misschien wel, enz.
Is het in de wijzigingsset omschrijving toegestaan om een link op te nemen die dan ook aanklikbaar is ? Want als dat zo is dan is dat de meest recht-toe-recht-aan oplossing denk ik !
Aan de andere kant: als de volgende mapper daarna een klein dingetje bijvoorbeeld een velditem toevoegt en weinig doet met de wijzigingsset omschrijving is de hele link met info niet meer te zien…
In ieder geval zijn keys (velden) in de OSM database altijd met kleine letters, al kan een toepassing dat op het scherm natuurlijk anders doen.
Misschien is een lifecycle prefix bruikbaar, ev samen met een note en/of een van de date keys?
Gewone gebruikers laten meegenieten van toekomstigheden is niet echt OSM. OSM hangt erg aan het nu: wat je ziet is wat je mapt, en de toekomst zien we dan wel weer.
Aan bv knooppuntnetwerken heb ik gemerkt dat geplande knooppunten en routes tamelijk vaak ofwel niet doorgaan, ofwel heel lang blijven liggen, en/of heel anders worden uitgevoerd dan het plan was, terwijl ze in de officiële planners al worden doorgevoerd. Beter niet doen, al heeft men in Vlaanderen wel een schema bedacht en gebruikt met een proposed: prefix, waar 1 OSM-toepassing (Knooppuntnet Planner) en een commerciële planner, gebouwd voor een grote gemeente, ook gebruik van maken. Ik dacht met een keuzevakje “Ook geplande routes weergeven”.
Ja hoor dat kan/mag zeker. Wat leesvoer over de comment tag bij een wijzigingsset: Good changeset comments - OpenStreetMap Wiki en Key:comment - OpenStreetMap Wiki
Wat leesvoer over een changeset zelf en wat daar nog allemaal aan te hangen is: Changeset - OpenStreetMap Wiki
Lost alleen nog niet het aangemerkte probleem op dat als een volgende mapper in zijn changeset omschrijving op dat ge-edite object niet de link zet de info niet meer meteen zichtbaar is…
Ik heb in deze post alleen de naam willen laten opvallen vandaar de hoofdletters…
Ook dat weet ik maar: in de BAG import waar ik deze post mee startte
Verhelderde de link wel de ontstane verwarring… Een verwarring die je eigenlijk voor wil wezen NIET alleen voor forumlezers die editen maar ook voor andere OSM-editors…
Ik weet dat in Haarlem infrastructuur/bouw-projecten door 5 inspraak ronden moeten voordat de ontwerpfase aanbod komt & de ontwerpfase ronde komt pas in beeld als financiën rond zijn voor deze projecten…
De kans dat projecten in Haarlem niet of anders uitgevoerd worden is daardoor vrijwel nihil…
Ik heb alle tips & reaktie’s tot nu toe gelezen & 1 nacht erover kunnen slapen over het door mij gestartte topic.
Daar waar verheldering nodig is zal ik met opmerkingen werken in de vorm van:
note= TOEKOMST:
note= HULP:
Waarbij: Toekomst notes gedefineerd als zeer nabije toekomst. (lees als: ontwerpfase en bouwfase).
Als voorbeeld: Changeset: 135222355 | OpenStreetMap
Als er nog betere voorstellen komen naar aanleiding van bovenstaande Changeset voorbeeld is alle input welkom nartuurlijk !
Daarbij aangevend dat IK voorlopig zo mijn aantekeningen veld zal vullen en hoop dat er of navolging of doorontwikkeling op dit idee gaat plaatsvinden.
Ik zou veel meer voelen voor de note:xxxxx constructie.
Die wordt redelijk vaak gebruikt en wordt ook goed begrepen.
https://taginfo.openstreetmap.org/search?q=note%3A#keys
Nadeel bij jouw oplossing is dat een niet-nederlands sprekende mapper weer niet begrijpt wat je bedoelt met note=TOEKOMST:
Maar note:future=tekst van de note geeft een oplossing die aansluit bij wat er al is.
Inderdaad zoals Marc zegt is iets als note:future beter. Dit topic gaat over het in het leven roepen van een toekomst-opmerkingen veld, wat ik interpreteer als een aparte tag voor toekomst-opmerkingen. Als je een aparte tag wil maken moet de key uniek zijn. Dus note:future i.p.v. note.
Super oplossing heren !
Eerlijkheidshalve wist ik niet dat deze oplossing bestond omdat ik 'm nog nooit in de praktijk gezien had…
Verder wilde ik voorstellen om mijn normale note constructie voorstel voor OSM NL dan te gebruiken voor: HULP & BAGIMPORT volgens de constructie die ik dan eerder voorstelde voor: HULP en TOEKOMST .
Immers:
- de bagimport is juist iets wat uniek is voor OSM-NL , 2. geeft geen (tijdelijke) vervuiling op de kaart maar geeft voor de import verwerker toch een bruikbare link.
HULP geeft dan een onderscheid tussen de 2 notes vormen aan.
En eerlijk gezegt als OSM-NL editor wil ik graag liever een OSM-NL lid die mij helpt omdat deze kwa kans meer op de hoogte is van (verkeers)regels binnen Nederland & afspraken binnen OSM-NL als community…
Ook graag jullie mening en/of opmerking hierover.
Voor de duidelijkheid: Informatie in OSM wordt aangebracht met tags. Elke tag bestaat uit een key/sleutel en een value/waarde. In geschreven tekst worden tags weergegeven als key=value. In de meeste editors zijn er aparte velden voor de key en value en wordt het is-teken dus niet geschreven.
Een object kan in theorie oneindig veel tags hebben, maar niet meerdere tags met dezelfde key. In principe worden keys in kleine letters geschreven.
Je wil aparte tags, dus dan heb je aparte keys nodig. Bij opmerkingen kan dit door een specifieke suffix toe te voegen. Bijvoorbeeld note:future=, note:bag=, note:help=* etc, waarbij de * staat voor de opmerking zelf. Er worden dus géén hoofdletters gebruikt in de key.
Hoe zie je de BAG-import-opmerking eigenlijk voor je? Voor BAG-import is toch gewoon een topic op het forum? Waar dient de tag dan voor?
Misschien een onderwerp om in een online meeting te bespreken…
Het gesproken woord communiceert sneller &prettiger vind ik.
Als deze oplossing dan tevens met een andere kleur weergegeven wordt op de digitale kaart, bijvoorbeeld: geel of oranje met de letter: F op de voorgrond dan is denk ik het plaatje compleet…
Weke digitale kaart bedoel je? OSM Carto stijl op osm.org? Ik denk niet dat die dat gaat doen. Er is wel een opmerkingen-overlay die de notes laat zien, maar ik geloof niet dat die onderscheid maakt tussen soorten notes.
Je kan natuurlijk wel een overpass-turbo query maken die ze opspoort en op de kaart laat zien, maar of je de kleur en een ikoontje daarvoor kan instellen, weet ik niet. Ik kan het in ieder geval niet!
En dan zijn er ook tools waarmee je een eigen kaart met POIs kan maken.
Bijvoorbeeld met een MapComplete thema (ook op mobiele apparaten) kun je ze vinden, op de kaart tonen, aanklikken en bewerken, maar dan moet je wel een MapComplete thema maken.
En met OpenPOI map kan je ze vinden, maar ook daar zal je denk ik niet je eigen display stijl in kunnen stellen.