Dit is nieuw voor mij:
https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging_in_Netherlands
Zie ook hier: de node van de ‘railway milestone’ midden op de spoorlijn, tussen de rails [weet niet hoe ik naar een node moet verwijzen]
http://www.openstreetmap.org/edit#map=19/52.06562/5.30778
Precies dát, was vvoor mij de reden om verder te gaan zoeken waar ze vandaan kwamen, ik had ze nl. nog niet eerder gezien…
Hallo allemaal,
zojuist is me kenbaar gemaakt (via een reactie op de changeset) dat er op deze pagina wat vragen vallen te beantwoorden. Ik hoor graag wat jullie willen weten.
Groeten,
Jeroen
Student railbouw in Delft
Allereerst welkom op het forum, een import is aan regels gebonden vandaar dat er een reactie is gegeven op de changeset met een verwijzing naar dit forum en naar de import guidelines.
Ik zie dat Woodpeck_repair (Frederik Ramm) inmiddels de changeset volledig heeft gerevert.
De reden van reverting is: remove un-discussed railway milestone import
De reactie in de oorspronkelijke changeset wordt verwezen naar de regels om te kunnen/mogen importeren.
Bedankt voor de introductie. De guidelines kende ik inderdaad nog niet, zoals waarschijnlijk wel op te maken valt uit mijn reactie op de changeset. Ik zal ze doorlezen en de import erop aanpassen.
Na deze import staan er nog een hoop andere op de rol; de applicatie railmaps bevat namelijk exact ingemeten locaties van:
onderstations, schakelstations, autotransformatorstations, bovenleidingspalen, bovenleidingsportalen, draagsystemen, balises, deuren in geluidsschermen, de geluidsschermen zelf, meetkasten, seinen, signalering, reis informatie systemen, stations, perrons, slagbomen van overwegen, exacte punten van overwegen, overwegbevloeringen, spoorstaaflassen, stootjukken, mathematische punten (van wissels), spoorassen, wissels, kruisingen, spoorstaaf conditioneringssystemen, kilometerlinten, hectometerbordjes, hectormeterraaien, spoorhartlijnen en geocode(sub)gebieden.
Genoeg informatie dus. Het is duidelijk dat niet alles relevant is voor OSM, maar een groot deel kan met wat omtaggen meteen geïmporteerd worden.
In de richtlijnen staat dat bovenstaande met (in dit geval) de Nederlandse mappers overlegd moet worden. Dus de vraag: in hoeverre (en in welke vorm / niveau van detail) willen jullie hierover op de hoogte gehouden worden?
Het lijkt me handig om te weten dat er iets gaat worden toegevoegd, maar wat mij betreft is de vraag eigenlijk meer: “wie zijn die Nederlandse mappers met wie je moet overleggen”? Zijn dat de personen die het afgelopen jaar in dit forum hebben gepost, aangevuld met de mensen die op talk-nl hebben gepost? En wat is de functie van dat overleg? Moeten we allemaal akkoord gaan? Of 51%? of 2/3?
We hebben een grootschalige BAG import gehad, hoe is dat gegaan?
En dan de vraag: wat moet er worden geïmporteerd? Hieronder heb ik in jouw lijst gemarkeerd wat me nuttig lijkt:
Wat er uiteindelijk geïmporteert gaat worden daar kunnen we prima nog wel over discussiëren. Wat ik mij alleen ook afvraag is: waarom niet gewoon uploaden en wachten tot het door iemand afgeschoten wordt (waarna de changeset eraf gaat, a.d.v. het commentaar aangepast wordt en weer online gaat)? Het idee van gaan definiëren wie er allemaal akkoord zou moeten gaan en hoe lang al die reacties wel niet op zich gaan laten wachten, daar ben ik nou niet bepaald gecharmeerd van. Maarja ik ben hier natuurlijk ook maar nieuw he. 
Wat mij betreft, alles uploaden waar je zin in hebt, want:
omdat die discussie nu heeft plaatsgevonden. (Tenzij we van mening zijn dat meneer Woodpecker daar over gaat)
Misschien wil er iemand anders nog iets over zeggen?
Als ik de link die Commodoortje gepost heeft doorneem zijn er heel wat meer “bureaucratische horden” te nemen dan hier in een forum op een vrijdag namiddag even te handjeklappen.
Alles op de bonnefooi maar te uploaden levert je denk ik vrij gauw een geblokkeerd account op. Goede bedoelingen zijn niet genoeg denk ik, een portie doorzettingsvermogen om het proces te doorlopen lijkt onontbeerlijk.
Wat ik zelf nog wel zou willen zien zijn bijvoorbeeld de rails zelf in bijvoorbeeld het havengebied van Rotterdam met de juiste aantal sporenwissels en dergelijke. Ook de stootblokken horen daarbij, want veel meer relevant dan op de doorgaande personenlijnen. Verder denk ik dat Marc wel de meest interessante objecten eruit heeft gepikt.
Heb zelf al een en ander geprobeerd correct te mappen, maar luchtfoto’s zijn niet altijd nauwkeurig genoeg, er veranderd wel eens wat en een groot deel ligt ook op afgesloten bedrijfsterreinen, zodat je niet gemakkelijk kunt meereizen met je GPS om de track op te nemen.
Sander
Al eens geprobeerd om dan gewoon, bv bij Kijfhoek, aan de poort aan te kloppen en toestemming te vragen ? Ik twijfel wie de eigenaar of beheerder is, maar ga daarbij uit van een zeker optimisme, nee heb je en ja kun je krijgen, zie Blijdorp. En ja de veiligheid en de kwetsbaarheid, chemische transporten vormen voor Kijfhoek een moeilijk te nemen drempel.
Wat ik me afvraag:
- Hoe ga je om met bestaande data?
- Hoe gaat deze data onderhouden worden? gezien de mate van detail lijkt me dit veel werk en als dit niet gedaan wordt dan zitten we vrij snel met gedetailleerde en verouderde data. Dan heb ik liever beperkte data die wel klopt.
- Wat is de toegevoegde waarde van deze data voor osm?
- Oftewel; door wie en voor wat gaat deze data gebruikt worden.
Die vraag heb ik me de afgelopen jaren wel vaker gesteld over allerlei toevoegingen aan de database. Ik kom (nu ik met taglocator bezig ben) steeds vaker volkomen onbegrijpelijke gegevens tegen, maar er schijnen dan toch altijd weer toepassingen te zijn die nu juist die data gebruikt.
En er is dus ook vast wel iemand die nu net op zoek is naar de stootjukken, mathematische punten (van wissels), en spoorstaaf conditioneringssystemen om daar mee een toepassing te schrijven waar iedereen enorm blij van wordt en die de oplossing blijkt te zijn voor alle problemen waar Prorail mee worstelt. Vervolgens kan de NS plotseling alle treinen perfect op tijd laten rijden en hebben we nooit meer vertraging.
Dat zal ik ook zeker niet ontkennen; ik heb de guidelines immers gelezen. Inmiddels heb ik me aangemeld voor de relevante mailing lists en ben ik bezig met het samenstellen van een mail zoals beschreven in de link.
Ik heb eerder inderdaad gemerkt dat de haven van Rotterdam bar slecht gemapt is. Echter snap ik je punt niet helemaal; de dataset bevat álle (helemaal compleet dus) sporen die in beheer van ProRail, Keyrail en Infraspeed zijn. Hier vallen dus ook rangeerterreinen zoals in de Rotterdamse haven en heel Keifhoek onder. De spooraansluitingen staan er zo goed mogelijk op; daar waar dus stukken ontbreken ontkom je er dus niet aan om zelf dat laatste stukje verder te mappen. Echter lijkt me dat te overzien; waardoor dit wat mij betreft geen afbreuk doet aan het nut van de dataset.
- Van het deel van de data dat ik wil importeren (verschijnt zo snel mogelijk een mail over op de import mailinglist) is er alleen maar bestaande data van stootjukken en spoorlijnen. Dit deel van de import doe ik als laatst. Ik had het als volgt in gedachte: open changeset, importeer rail objecten per behapbaar stuk spoor, tag railmaps objecten om naar OSM tags, voeg extra tags toe adv de bestaande objecten, verwijder de bestaande objecten, sluit de changeset.
- De data kan onderhouden worden door goede instructies voor het updaten ervan. Voor objecten die andere objecten niet beïnvloeden geldt: oude changeset (toevoegen) ongedaan maken en nieuwe versie voor heel Nederland in 1 keer uploaden (denk aan bijv. aan de hectometerpaaltjes). Voor het spoor geldt maatwerk; die data zal getagd worden als ‘vrij bewerkbaar in geval van wijziging van layout sporen’ (en ja, dan moeten we op dat stuk genoegen nemen met minder detail). Mocht iemand een manier weten om dit automatisch te doen zoals bij de BAG update tool, dan is die persoon een held.
- Zie bijvoorbeeld openrailwaymap.org
- Voor een spoorwegingenieur (wat ik over een jaartje of twee hoop te worden) is bijvoorbeeld een kaart met de kilometrering en de locatie van bijvoorbeeld seinen ten opzichte daarvan erg nuttig. Dit kan allemaal via ORM, zolang de data er maar is.
JJJWegdam, bedankt voor het beantwoorden van mijn vragen.
Osm is een community die zwaar leunt op lokale mappers en deze zijn makkelijk te demotiveren door er met een import overheen te walsen. Je maak namelijk uren handwerk ongedaan en hoe goed je dataset ook is, er gaat altijd wel een detailtje verloren dat door een lokale mapper was toegevoegd. De gedachte is dat het beter is een goede community op te bouwen dan je te richten op grootschalige imports. Dit dan ook is de rede dat voor je aan je import begint er samenspraak met en instemming van de lokale community moet zijn.
Hoewel mijn reacties misschien anders doen lijken, sta ik helemaal niet zo kritisch tegenover imports. Wel vind ik het belangrijk dat bepaalde stappen in het officiële proces Goed worden afgehandeld. Wat ik zelf het belangrijkst vind is: instemming van de community, documentatie en nadenken over het onderhouden van de data.
Dan nog een paar praktische puntjes:
- Om de meest ingrijpende zaken voor het laatst te bewaren is een goed idee.
- Als je grootschalig data gaat verwijderen/overschrijven, doe dit dan in overleg met de mappers die dit oorspronkelijk hebben toegevoegd/aangepast.
- Het wordt als een zonde gezien om data weg te gooien en opnieuw te tekenen. (de geschiedenis van een object gaat dan verloren) Beter is om bestaande data aan te passen. Gelukkig zijn er tools om je hierbij te helpen.
- Ook de keuze van de te gebruiken tags valt onder het kopje “instemming van de community”.
Succes met dit project!
JJJWegdam,
, vallen daar dan ook de kunstwerken onder die zorgen dat het spoor geen hinder ondervindt van kanalen en wegen en de hellingen op rangeerterreinen ?
Op dit moment ben ik bezig een kaart voor Garmin te ontwikkelen met alleen spoorse gegevens (Dat valt nog niet mee… 
Wat dat betreft zijn hectometerpalen (plaatsbepaling) als eerste welkom maar ook lichtseinen zijn nuttige punten om de plaats te bepalen.
Voor wat betreft de ligging van het spoor zitten er nu in OSM op een aantal plaatsen onvolkomenheden die dan misschien ook opgelost zijn
Ik heb dit zelf ondervonden door een aantal van m’n gebouwen, die vervangen werden door BAG. Ik onderken deze uitdaging dus zeker. Dit hoop ik op te lossen door wat ik hieronder beschrijf bij ‘2.) & 3.)’. Kan je je daarin vinden?
Zeer begrijpelijk.
2.) & 3.): ‘’…and the new way has all the tags and relations of the old one.‘’ Bedankt voor deze verwijzing. Het klinkt me zelfs dermate nuttig dat het me lijkt dat dit garandeert dat bestaande tags waar handmatige moeite in is gestoken behouden blijven. Dit zou wat mij betreft 2.) overbodig maken. Qua geometrie is mijn mening namelijk ‘de data is per definitie beter aangezien het professioneel ingemeten is’ en qua tags is alle moeite gegarandeerd behouden. ( 3.) is bij gebruik van deze manier wat mij betreft ook opgelost).
4.): Ik werk aan een mail aan de import en talk_nl mailinglists. Een voorproefje vind je/u hieronder:
Tegen de tijd dat deze sheet klaar is zal ik (naast de beide mails) ook een tekstversie hier posten, zodat er via quotes specifieke delen besproken kunnen worden. Graag hoor ik tegen die tijd jullie mening.
Gegevens zoals taluds, kunstwerken en stationsgebouwen zijn in te zien (zie onderstaand plaatje). Zoals je misschien al gemerkt hebt, staan ze helaas niet in het rijtje van objecten dat geëxporteerd kan worden. De shapes met de locaties van sporen (spoorassen in Railmaps) negeren dus het passeren van kunstwerken.
Leuk initiatief. Ik kan me zeker vinden in je prioriteiten.
Nu we het toch over treinen hebben…
Kenden jullie deze al?
http://tracker.geops.ch/?z=9&s=1&x=611779.4975&y=6840157.0274&l=transport
Hip. Die kende ik nog niet. Ik neem aan dat jullie http://kubus.mailspool.nl/spoorkaart/ al kenden?
NS is trouwens bezig om GPS transmitters van treinen te gaan gebruiken om de daadwerkelijke locatie van treinen te gaan weergeven op een openbare kaart. Let wel: mailspool en geops gebruiken de theoretische locatie o.b.v. de dienstregeling.