Met tourism=artwork + artwork=graffiti geef je aan dat het een kunstwerk betreft. Dat klopt, als iemand er inderdaad gebruik van maakt.
barrier=wall is een tweede hoofdtag, en deze vind ik minder van toepassing. Het is niet een barrier, maar een voorziening, een amenity. Bijvoorbeeld amenity=graffiti_wall.
wall=metal vind ik ook niet zo gelukkig, ik denk eerder aan material=metal.
PS terzijde
artwork_type is een van die onzalige ..type.. sleutels waaraan ontbreekt waar je naar kijkt om de onderverdeling te maken. Het gevolg is dat er een mengelmoes aan waarden komt die gebaseerd zijn op functie, techniek, materiaal, cultuurgebonden benamingen, symboliek en gewoon veelvoorkomende types.
Ja, en dat vereist eerst tunnel=culvert.
waterway=culvert + culvert=pipe zou ik logischer vinden. Maar voor Engelstaligen lijkt tunnel=culvert wel normaal te klinken, dus ik zal het ermee moeten doen!
Op de diverse waterway-wiki’s worden ditch en drain nogal geklutst, lijkt het. Ik vermoed dat pagina’s gekopieerd en aangepast zijn, waardoor er wel eens iets bleef staan wat eigenlijk aangepast had moeten worden.
Maar ik ga voortaan waterway=drain gebruiken voor culverts tussen waterpartijen die niet duidelijk een doorlopende waterway vormen.
Bij een door duikers opgehakte sloot blijft de duiker waterway=ditch, bij een hoofdsloot of tocht blijft de duiker waterway=canal, en net zo voor river en stream.
Grote culverts
Over het mappen van grote culverts als closed way voor de omtrek hebben we het al eens gehad, zonder duidelijke consensus, denk ik? Wat mij betreft is dat vergelijkbaar met man_made=bridge waar wegen vastgeknoopt en getagd met bridge=yes layer=1 overheen lopen: man_made=culvert met waterway=…, tunnel=culvert en layer=-1 vastgeknoopt. Het watervlak kan daarbinnen gemapt worden.
Ik zie steeds meer van die units gebouwd worden die gehuurd kunnen worden als opslagruimte, zowel zakelijk als particulier. Zie bijvoorbeeld deze die recent is opgeleverd : Opslagruimte Velddriel
Een aantal bestaande die ik bekeken heb in osm hebben vanuit de BAG-import de tag building=industrial of building=office gekregen. Wat zou juist zijn? (building=commercial en dan een description dat het opslagruimte te huur betreft?) Of anders?
In NL worden die opslagruimtes soms garageboxen vanwege de vorm, maar ik denk dat dat geen algemeen gebruik is, als er geen voertuigen in gestald worden. Dus voor mij is Tjuro’s shop=storage_rental de beste bestaande kandidaat!
Ik sluit me vooralsnog hier bij aan. Zal mijn voorbeeld op die manier gaan mappen.
Edit: ik heb het hele gebied landuse=commercial gegeven, node geplaatst met shop=storage_rental en benodigde gegevens en de gebouwen zijn building=warehouse nu.
Waar plaatsen jullie de way van een highway=residential met aan één kant een brede stoep? Is dat in het midden van de hoofdrijbaan, of in het midden van de hele straat?
PS ja je kan de stoep apart intekenen als footway, maar standaard wordt dat op residentials niet gedaan, dus die oplossing zoek ik niet! Ik wil gewoon de al ingetekende straatjes rechtleggen en uitlijnen.
Kent iemand een functie/plugin in JOSM die lijnen ( al dan niet gesloten) gladder maakt door punten tussen te voegen? Bijvoorbeeld een rotonde die tussen elke twee punten een extra punt moet krijgen, of een bocht die nu met twee hoeken getekend is maar eigenlijk mooi vloeiend loopt?
Dank, maar dat is niet precies wat ik zoek. Circle arc en W zijn punt-georienteerd, en ik wil een hele lijn vloeiender maken. O voegt geen punten in, dus die maakt de ronding wel gelijker maar verhoogt de precisie niet.
Dus zo zie ik het voor me: ik selecteer een heel wegdeel, en de functie neemt telkens de volgende hoek tussen twee lijnstukjes, en verdeelt die in twee kleinere hoeken door een (iets verschoven) punt in het eerste lijnstuk in te voegen.
Handmatig is dat in JOSM: het pakken van een plusje (wordt punt) en iets verschoven neerzetten. Dat doe ik nu visueel, maar de juiste plek van de tussengevoegde punten kan ook berekend worden, en dan automatisch de volgende doen. Hij laat dus de bestaande wegpunten, en wat daar ev. aan vastzit, ongewijzigd.
De maker van de KindaHackedUtils plugin noemde dat hij nog een tweede, nog snellere plugin had gemaakt om nodes aan lijnen toe te voegen.
KHU heeft al de B toets… positioneer de muis boven de doel-lijn, tik B en de node zit op zijn plaats. Het omgekeerde van Simplify werkt helaas niet , met de instelling kan je bepalen hoeveel nodes je per afstands eenheid wilt behouden, maar als je het op extreem zet, per 0.01 of zo dan voegt die niets toe.
Ook dat is punt voor punt neerzetten, ipv zoveel punten toevoegen en positioneren als nodig is om een gekozen way vloeiender te maken. Het is denk ik vooral lastig om te zorgen dat er geen onbedoelde afrondingen gebeuren. Er zijn vaak rechte stukken en bedoelde hoeken, die moeten dan niet worden opgedeeld of afgerond. Ik zou in ieder geval zeggen dat-ie van te lange lijnstukken en van te scherpe hoeken af moet blijven, bv meer dan 10 meter en meer dan 40 graden uitsluiten.
Vaak split ik een weg tijdelijk, dat wat rond en dat wat niet, dan de nodes kiezen van het te ronde stuk (arc of volle cirkel ) met shft+ctrl+N en O om de nodes netjes in de curve te verdelen. Nadien de stukken weer mergen met C. (meesten dacht ik UtilsPlugin2 functies). IIG de B functie werkt snel genoeg voor mij.
(die nodes toevoegen en verdelen en rond maken in 1 slag is nog niet uitgevonden NMW).
