[OSM-talk-nl] Wegaanpassingen via www.staatscourant.nl

[Gertjan Idema]

Ik zit ook al een tijdje in die richting te denken, mede naar aanleiding
van mijn ervaringen met BAG data in OSM.

Inmiddels ben ik begonnen met een Josm plug-in voor dit doel.
De functionaliteit die ik nu heb is als volgt:
- Selecteer via het menu (of via een toolbar) een open data verzameling
(Bijvoorbeeld NWB - Nationaal wegenbestand)
- Geef een download gebied aan (net als met de normale OSM download)
- Converteer deze data naar OSM formaat en bied ze aan in een aparte
laag.

Dit heb ik nu werkend voor de volgende open data:
- NWB (op basis van WFS service
http://geodata.nationaalgeoregister.nl/nwbwegen/wfs)
- ProRail Sporen (Op basis van Arcgis REST service
http://mapservices.prorail.nl/ArcGIS/rest/services/)
- BAG panden (Op basis van Geoserver WFS service op mijn locale systeem)

Naast het genereren van een Josm data laag, wordt de data ook in
specifieke Java objecten bewaard. Dit biedt mogelijkheden om geven
tussen verschillende lagen te vergelijken (Bijvoorbeeld straatnamen in
BAG vergelijken met dit in NWB).
Ook zou je hiermee bijvoorbeeld de history van een BAG object kunnen
bekijken. Een gesloopt pand wil je meestal niet in de data laag hebben,
maar als het pand nog in OSM staat wil je wel kunnen zien dat het
volgens BAG inmiddels gesloopt is.

Ik probeer het zo modulair mogelijk op te zetten, zodat het eenvoudiger
wordt om nieuwe datasets toe te voegen.
De status is op dit moment nog erg experimenteel, maar omdat het volgens
mij aardig aansluit bij jouw ideeën wou ik ieder geval even laten weten
dat ik hier mee bezig ben.

Gertjan Idema 


On Wed, 2013-01-02 at 23:49 +0100, Robert Elsenaar wrote:

> Ik kreeg ook steeds vaker die indruk. Naar mijn idee moeten wel dan zo
> langzamerhand hand denken aan een andere generieke manier om niet de
> data op een min of meer generieke manier voor OSM beschikbaar te
> krijgen,  maar voor de mappers van OSM. 
> 
> Ik denken daarbij aan een soort 'containers'  waarin voorbewerkte josm
> layers of anders soortgelijke informatie te vinden is. Je kunt dan
> denken dat iedere container een map gebied vertegenwoordigd. 
> Belangrijk is dan dat de toch redelijk technisch ingewikkelde data
> verwerkingsklaar in de containers beschikbaar is. Op die manier zijn
> er meer osmers die in staat zullen zijn om de gegevens naar OSM te
> brengen. 
> Wat denken jullie van deze visie. Ik zou er graag eens over verder
> willen praten. 
> 
> 
> Achtergrond: ik heb al tijden de wens om mee te helpen met inbrengen
> van open data,  maar heb niet de technische geopend kennis om mij
> verdienstelijk te maken. Graag zou ik dat echter voor de omgeving van
> Putten wel willen doen. 
> 
> 
> 
> Met vriendelijke groeten 
> Robert Elsenaar 
> 
> 
> 
> 
> Stefan de Konink <stefan at konink.de> schreef:
> 
> 
> On Tue, 1 Jan 2013, Robert Elsenaar wrote:
> 
> > Is mijn indruk correct dat er steeds meer data wel beschikbaar is en
> > geschikt voor verwerking in OSM, maar dat geautomatiseerd robotisch
> > toevoegen van deze gegevens of niet mogelijk of onwenselijk is?
> 
> Nouja ik ben wel eens bij een bespreking van I&M hierover geweest. En
> er 
> zijn natuurlijk koppelvlakken te bedenken waarop dit werkt maar dit 
> integreert niet naar jouw eigen eind oplossing totdat je zelf een 
> converter maakt.
> 
> Het datamodel van OSM is voor een aantal dingen zoals robotisch
> toevoegen 
> gewoon niet geschikt. Op welke wegvlakken is het bord van toepassing
> is 
> een vraag relevant voor OSM, terwijl andere toepassingen genoegen
> nemen 
> met een X,Y van het bord.
> 
> 
> Stefan
> 
> _______________________________________________
> Talk-nl mailing list
> Talk-nl at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl
> 
> 
> _______________________________________________
> Talk-nl mailing list
> Talk-nl at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-nl/attachments/20130109/5df579c4/attachment.htm>