Als nieuwe OSM-gebruiker (ik durf mezelf nog geen “mapper” te noemen) heb ik, met hulp van Eggie, al een paar eerste bewerkingen gemaakt. (nog bedankt Eggie!)
Nu heb ik een aantal vragen voordat ik de volgende bewerkingen durf te maken.
Ik zie een aantal gebouwen met de naam van de winkel (of het restaurant of whatever) dat erin zit. Maar volgens mij zou die winkelinformatie (of restaurantinformatie) op de adresnode moeten komen? Tenminste, dat maak ik op uit het 3e puntje op: http://wiki.openstreetmap.org/wiki/Welkom_op_OSM#Waar_moet_je_op_letten_als_je_de_kaart_gaat_bewerken.3F
Mijn vraag is nu: mag ik dat zomaar bewerken? Dus: tags bij het gebouw verwijderen, en tags bij de adresnode toevoegen?
Ik zie een aantal notes die resolved zouden kunnen worden. Bijvoorbeeld, in een note staat dat een bepaald bedrijf is verhuisd en dat er nu een ander bedrijf op desbetreffend adres gevestigd is. Nadat ik dat heb aangepast, mag ik dan zomaar die note op “resolved” zetten?
Ik heb vast nog wel meer vragen maar die komen ongetwijfeld vanzelf.
Iedereen krijgt hetzelfde vertrouwen op OSM. Je merkt dat meteen als je ziet dat alles, in al zijn kwetsbaarheid, ter beschikking staat. Het getuigt van de juiste instelling dat je hier voorzichtig mee om gaat en vragen stelt.
Als je 't zeker weet mag je het natuurlijk veranderen. Alleen even opletten dat er op dat moment niemand mee bezig is. Toen ik begon wou ik ook niet zomaar andermans nodes aanpassen en plaatste ik de winkel-nodes ernaast. Ik heb nu dus vele winkels zonder adres die weer gewijzigd moeten worden, sowieso dus handiger dit meteen goed te doen.
Als je een onopgeloste opmerking oplost is het inderdaad ook de bedoeling dat je 'm op “opgelost” zet. Niet dat anderen gaan zoeken naar een probleem dat er niet (meer) is…
kan iemand er 1 argument aan toevoegen waarom dat zo is (dus waarom niet op een gebouw)? Want als je de reden leest en logisch vind onthoud je de reden waarom het beter op de adres node kan.
Welkom op OSM! Hopelijk vind je het leuk en blijf je lang mappen!
Bij de adresnodes moet je goed kijken want vaak worden de adressen geimporteert en allemaal op elkaar gestapeld. Als je een adres wil vinden moet je de stapel nodes 1 voor 1 van elkaar wegplaatsen om de juiste node te vinden. En daarna krijg je ze niet meer op elkaar. Er is misschien een manier, maar zo ver ben ik ook niet :F. Ik doe dan altijd een node apart voor winkels, en sommige winkels hebben 1 adres maar staan onder 2 gebouwen. Dus dan plaats ik de node in het midden om te laten zien dat het een grotere winkel is. En sommige winkels blijven maar een jaar open en gaan ze weg. Dus je kan daarna gewoon delete op de node drukken zonder dat er aan de adressen wordt gezeten.
Het is altijd een beetje zoeken wat het beste is.
Nou zo doe ik het, misschien weten anderen meer raad.
Welkom op het forum. OSM hangt van consensus aan elkaar. … en dit is één van die afspraken. Vaak na ellenlange discussies. Wanneer je name=… op het gebouw zet krijgt het hele gebouw ook prominent die naam, terwijl er vaak ook andere bedrijven of woningen aanwezig zijn. Dat klopt dan dus vaak niet.
Dat is één goede reden. Bovendien is er dan een koppeling tussen de adresgegevens op de node en het bedrijf. Bij zoekslagen in de gps zie je bv direct het telefoonnummer staan.
Wanneer een bedijf verdwijnt dan niet de node wissen, want hier staan de BAG-gegevens op. Alleen de naam en aard van het bedrijf. Vervolgens opnieuw aanvullen.
In ieder geval zodat de winkel een adres heeft, er zijn apps die deze (winkel)info representeren en zonder adres is het dus incompleet.
Het gebouw zelf heeft geen adres, daar is de adres-node voor. Verder is het niet de bedoeling dat er dubbele adres-nodes ontstaan doordat de bestaande adres-node wordt genegeerd en nogmaals een adres aan een winkel-node wordt toegevoegd. Het gaat er dus eigenlijk om dat bestaande info wordt samengevoegd (winkel+adres+enz.) en niet wordt gefragmenteerd over verschillende nodes o.i.d.
Ook als het een kerk is, of een theater, of een gemeentehuis wordt het hele gebouw getagged. Waarom bij winkels dan niet? Ik denk dat het verschil is tussen het aangeven van een ** type gebouw (adres onafhankelijk)** en ** gebruik van -een deel- van het gebouw -
(soms adres afhankelijk)**. Op die manier kan ik het onthouden.
Je zet alleen een naam op een gebouw als dat gebouw als zodanig bekend staat; vaak bij bv. een museum, kerk, paleis, stadhuis.
Winkels, kantoren etc. zijn meestal niet aan één bepaald gebouw gebonden; ze verhuizen naar een andere plek, er komt een andere zaak op de oude plek; ze zijn alleen aan een adres gebonden voor zolang het duurt. Verder zijn er vaak meerdere adressen op één zo’n pand, bv. een winkel beneden en woningen boven.
Meerdere adresnodes in een gebouw zijn op deze manier mogelijk om aan te vullen
Adresnode kan in de buurt van de ingang geplaatst worden, routeerder kan beter de eindbestemming bepalen.
Makkelijker bewerkbaar
Voordelen op pandcontour:
Helaas heeft de osm.org site geen rendering voor office=* Een bedrijf heeft meestal een naam op de gevel, deze kan dus op het pandcontour geplaatst worden met de aanvullende bedrijfstags
Er is ook nog de mogelijkheid van de building:part tag.
Bij het outletcentrum had iemand de gebouwen in vele delen gesplitst om de winkels in te voeren.
Bij een BAG update (de contouren in OSM klopten niet en er is een uitbreiding) heb ik de tags op een gedeelte met building:part gezet. Dat leek mij het meest correct zonder het werk van iemand anders te veel aan te passen/vernielen.
Er zitten wel een paar voordelen aan een naam op een adresnode:
Een groot gebouw krijgt een duidelijk grote naam (vind ik een voordeel, anderen misschien een nadeel).
Een naam komt altijd te voorschijnen op openstreetmap.org. Bij een adres node alleen als een extra tag (bv. shop=) bekend is en gerenderd wordt.
In een winkelcentrum zijn de namen op de nodes het handigst. Er liggen vaak ook woningen boven.
Bij een industrieterrein waar de bedrijfsnamen wel bekend zijn, maar ik geen flauw idee heb van welke andere tag zet ik deze op het gebouw (tenzij er meerdere bedrijven gevestigd zijn).
Allereerst bedankt allemaal voor het warme welkom, en voor de uitgebreide informatie!
Het is goed om te merken dat hier op een volwassen en opbouwende manier een discussie gevoerd kan worden.
Voor nu houd ik me inderdaad aan de richtlijn die Michiel M beschreef (dus type gebouw vs. gebruik van gebouw). Ik denk dat het wel een kwestie van gevoel blijft maar het is voor mij nu al wel een heel stuk duidelijker.
En ook de opmerkingen waarvan ik zeker weet dat ze opgelost zijn, durf ik nu op te lossen.
Ook ik heb een beginnersvraag, mag ik daarom dit topic gebruiken? Ik ben in de Beemster af en toe bezig met water/sloten toe te voegen waarbij ik onderscheid maak tussen een vlak met water (natural:water water:ditch) of een lijn als ‘waterway:drain’. Het onderscheid is lastig te maken maar daarbij hanteer ik nu een breedte van meer dan ca. 2,5.
Tot nu toe werk ik met iD maar probeer over te stappen naar JOSM. Probleem is dat ik sommige sloten als een multi-polygoon heb gedefinieerd (zie bv. deze link) en aan elkaar geknoopt. Dat ziet er weliswaar ‘leuk’ uit maar het is mij niet gelukt om enkele sloten nu samen te voegen. Kan ik een polygoon of meerdere polygonen samenvoegen en er alsnog een vlak water van maken? En als er misschien iemand is die een kleine (eenvoudige?) uitleg kan geven over multipolygonen (wanneer te gebruiken, waarom) dan zou dat fijn zijn. Ik heb getracht de wikitekst over multipolygonen te begrijpen maar da’s mij niet gelukt
Er zijn voornamelijk twee redenen een multipolygoon te gebruiken:
Een stuk landuse wordt geheel omsloten door een ander soort landuse, bv. een eiland met gras gelegen in een meer. Er wordt dan een multipoly gemaakt waarbij de omtrek van het meer ‘outer’ is en de omtrek van het eiland ‘inner’. Zonder multipoly zou het eiland zowel water als gras zijn. Door de multipoly te gebruiken, wordt aangegeven dat alleen het stuk water minus het eiland echt water is.
Een ‘weg’ is dusdanig lang/groot dat het ondoenlijk is dit als één stuk te tekenen/onderhouden. Het wordt in stukken verdeeld en de stukken worden gecombineerd in een multipoly. Voorbeeld is de kust van het IJsselmeer.
Advies: vermijd multipolygoon tenzij het echt nodig is.
Als je twee stukken water (landuse=water) tot één geheel wilt maken, kan dat in JOSM door ze beide te selecteren en dan Shift-J te kiezen. In de standaard kaart maakt het overigens niet uit of het twee stukken zijn dan wel samengevoegd, ziet er hetzelfde uit. Je kunt evenwel niet een gebied met water samenvoegen met een lijn met water (waterway).
Ik zal de twee multipolygonen die je daar in de Beemster hebt gemaakt ongedaan maken, want die kloppen echt niet (combinatie van vlakken met lijnen).
Nog weer een aanvullende vraag op m’n “adresnode”-vraag.
Ik ben nu winkelnamen aan het toevoegen in een winkelcentrum. Nu is een winkel gevestigd op huisnummer 9-15. Hier bestaan 2 adresnodes voor (9 en 15, de tussenliggende 11 en 13 hebben waarschijnlijk nooit bestaan). Maar hoe plaats ik nu 1 winkel op 2 adresnodes?
Pak zelf dan meestal een van de adresnodes (in dit geval 9) en zet daar de tags op. Maakt mij voor het gebruik verder niks uit.
Heb het ook wel eens op de complexe manier gedaan door een relatie te maken en daar de winkel tags op te zetten en daar dan de relevante adresnodes en de panden aan gekoppeld. Zijn verder weinig data gebruikers die daar mee om weten te gaan, dus meestal is de simpele rechttoe rechtaan manier het handigst.
Winkel is meestal officieel op slechts 1 adres gevestigd (per vestiging) en die huisnummer ranges zijn in mijn ogen enkel enkel om aan te geven “kijk mij toch eens veel winkelruimte hebben”.
Een aantal dagen geleden had ik intensief contact met EGGIE ivm mijn **beginners **activiteiten op OSM.
Ik heb een aantal aanpassing gedaan voor paden / fietspad aansluiting / glasbak.
Na diverse aanwijzingen van EGGIE is het nu opeens stil.
Ik zou graag willen weten of de aanpassingen correct zijn … of dat er nog wat aan moet gebeuren.
En hoe ik verder kan met evt. nieuwe aanpassingen.
Ook zou ik willen weten waar / wanneer ik in de ECHTE OSM kan zien dat mijn aanpassingen geïmplementeerd zijn.
Wie kan hier iets over zeggen?
