Re: [OSM-talk-nl] tile.openstreetmap.nl

[Gertjan Idema]

Goeie actie Stefan.

Misschien een mooi moment om nog eens te kijken of we de RD cöordinaten 
op hun plek kunnen krijgen. (Onze Lieve Vrouwentoren in Amersfoort op 
155.000, 463.000). Ik denk dat een update van proj4js naar een recente 
versie voldoende is.


Groeten, Gertjan


On 07/10/18 19:34, Marco van der Heide wrote:

Hoi,

Gelijk even een kijkje genomen en het ziet er netjes uit. Op een 
mobiel zijn de knopjes voor in en uitzoomen wat lastig, maar centreert 
wel mooi.


Groeten, Marco

On 7 October 2018 18:45:59 GMT+02:00, Pander OpenTaal 
 wrote:



On 10/07/2018 01:34 PM, Stefan de Konink wrote:

Goedemiddag, tile.openstreetmap.nl verwijst nu via squid naar
de tileserver van openstreetmap.org. De volgende urls zijn
beschikbaar: Via Cherokee: http://tile.openstreetmap.nl/
https://tile.openstreetmap.nl/ 


Super! Misschien linksonder die "2012" uitbreiden tot "2012 – 2018". Dat
kan zelfs met eenvoudige JavaScript zodat het huidige jaartal als
laatste wordt gemeld, zie
https://www.w3schools.com/jsref/jsref_getfullyear.asp

Deze uitbreiding doet mensen meer waarde hechten aan wat ze zien en het
niet te makkelijk (en abuis) afdoen met, o, dat is vast een oude kaart.
>

Rechtstreeks via Squid: http://tile.openstreetmap.nl:8080/ Er
zal in de komende periode nog genoeg moeten gebeuren, maar dit
toont in ieder geval de meest actuele data van Nederland weer,
met als bijvangst de rest van de wereld. 



Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Locaties van EAD's iets voor OSM?

[Gertjan Idema]

Ik zou dit alleen doen in nauwe samenwerking met aed4.eu, als zij hier
meerwaarde in zien.
Voor AED's is toegankelijkheid cruciaal. Iedere AED in openstreetmap zou
daarom voorzien moeten zijn van openingstijden. Maar wij kunnen niet
garanderen dat die data onderhouden wordt. En zelfs al wordt de AED data
in OSM nauwkeurig bijgehouden, je hebt er niets aan als iemand deze
gegevens op een statische kaart zet.

Gertjan




On Wed, 2015-09-02 at 11:19 +0200, Maarten Deen wrote:

> On 2015-09-02 11:12, Pander OpenTaal wrote:
> > Locaties van EAD's iets voor OSM?
> > 
> > https://www.aed4.eu/ en de database woont volgens mij bij
> > https://www.radboudumc.nl
> 
> AED's dus. 
> http://wiki.openstreetmap.org/wiki/Tag:emergency%3Ddefibrillator
> 
> Ik zou zeggen van wel.
> 
> Maarten
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] JOSM plugin ODS

[Gertjan Idema]

Maarten,

De melding komt niet van de ods-bag plugin, maar van de opendataservices
plugin. Als je die uit vinkt, ben je melding kwijt.

Gertjan

On Mon, 2015-07-06 at 16:13 +0200, Maarten Deen wrote:

> Zo te zien is de JOSM ODS plugin voor de BAG-data. Elke keer dat ik JOSM 
> opstart krijg ik een venster dat mijn ODS versie (0.4.10) out of date is 
> en dat ik naar de laatste versie (0.5.1) moet upgraden. Maar in de 
> plugins heb ik ods-bag niet aangevinkt en dan nog staat ook daar versie 
> 0.4.10 genoemd, niet 0.5.1.
> 
> Weet iemand hoe ik van die melding af kom?
> 
> Maarten
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] RDM op OSM

[Gertjan Idema]

Wat bedoel je precies?

Op de Nederlandse OSM site http://www.openstreetmap.nl worden RD
coördinaten getoond.

 Gertjan

On Wed, 2015-02-04 at 09:06 +0100, Pander OpenTaal wrote:

> Is het mogelijk om RDM (Rijksdriehoekmeting) te tonen of op te zoeken op
> OSM?
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Taglocator met links

[Gertjan Idema]

De bug waardoor het niet werkte in Chrome is er uit. Verder heb ik de
opmaak van adressen wat eleganter gemaakt.
Dat je heel precies moet klikken is inderdaad niet ideaal. Dat is denk
ik wel te verbeteren door voor de details op osm object id te selecteren
in plaats van een gebiedje te downloaden. Dat zou ook het voordeel
hebben dat je bij vlakken (ways) niet perse op de randen hoeft te
klikken. Ga ik binnenkort eens mee spelen.

Gertjan

On Thu, 2014-12-25 at 20:47 +0100, Seijo Kruizinga wrote:

> De locator werkt ook onder IE. Het valt mij wel op dat je erg precies in 
> het midden van een cirkel moet klikken om de gewenste informatie te 
> krijgen. Seijo
> Marc Zoutendijk schreef op 25-12-2014 14:12:
> > Op 25 dec. 2014, om 10:10 heeft Gertjan Idema  het 
> > volgende geschreven:
> >
> >> Met welke browser heb je getest? Bij mij werkt het in Firefox
> >> Ik zie nu dat het in Chrome bij mij niet goed gaat. IE heb ik niet. Na de 
> >> feestdagen ga ik er naar kijken.
> >>
> > Het werkt niet in Chrome en Safari, wel in FF.
> > IE heb ik ook niet.
> >
> > Prettige feestdagen!
> >
> > Marc.
> >
> >
> >
> > ___
> > Talk-nl mailing list
> > Talk-nl@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-nl
> >
> >
> > -
> > Geen virus gevonden in dit bericht.
> > Gecontroleerd door AVG - www.avg.com
> > Versie: 2015.0.5577 / Virusdatabase: 4257/8803 - datum van uitgifte: 
> > 12/25/14
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Taglocator met links

[Gertjan Idema]

Met welke browser heb je getest? Bij mij werkt het in Firefox
Ik zie nu dat het in Chrome bij mij niet goed gaat. IE heb ik niet. Na
de feestdagen ga ik er naar kijken.

Gertjan

On Thu, 2014-12-25 at 09:58 +0100, Marc Zoutendijk wrote:

> 
> 
> Op 24 dec. 2014, om 23:47 heeft Gertjan Idema  het
> volgende geschreven:
> 
> 
> 
> > Het hoeft ook niet meteen perfect. Het is al een hele vooruitgang
> > wat we nu hebben.
> > 
> > Zelf heb ik ook een poging gewaagd. Het aantal resultaten is nog te
> > groot, omdat er nog geen filter op de geselecteerde objecten zit.
> > Anderzijds kan je daardoor informatie over willekeurige objecten
> > opvragen.
> > Kijk er maar eens naar: http://gertjanidema.nl/taglocator. Misschien
> > kunnen we volgend jaar 'the Best of 2 worlds' samenvoegen.
> > 
> > 
> 
> 
> 
> De link werkte oorspronkelijk niet omdat de afsluitende punt een
> onderdeel van de link vormt. Als ik dat corrigeer kom ik uit bij een
> kaart waarop allen het keuzemenu links is te zien, en rechts kan ik
> kiezen uit 4 kaartlayers. Maar uit het menu links kan ik niets kiezen
> en rechts ontbreken dus alle keuzemogelijkheden voor de tags.
> 
> 
> Ik zie in de code wel waar je mee bezig bent, en zal kijken of het
> hier lokaal wel werkt.
> 
> 
> groeten,
> 
> 
> Marc.
> 
> 
> 
> 
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Taglocator met links

[Gertjan Idema]

Het hoeft ook niet meteen perfect. Het is al een hele vooruitgang wat we
nu hebben.

Zelf heb ik ook een poging gewaagd. Het aantal resultaten is nog te
groot, omdat er nog geen filter op de geselecteerde objecten zit.
Anderzijds kan je daardoor informatie over willekeurige objecten
opvragen.
Kijk er maar eens naar: http://gertjanidema.nl/taglocator. Misschien
kunnen we volgend jaar 'the Best of 2 worlds' samenvoegen.

Prettige feestdagen,
Gertjan

On Wed, 2014-12-24 at 21:29 +0100, Marc Zoutendijk wrote:

> 
> 
> Op 24 dec. 2014, om 20:18 heeft Gertjan Idema  het
> volgende geschreven:
> 
> 
> 
> > Osmose (http://osmose.openstreetmap.fr) geeft een duidelijk
> > overzicht van verkeerde wikipedia tags.
> > Selecteer 'all severity' en 'wikipedia' om de wikipedia fouten te
> > vinden.
> > 
> > 
> 
> 
> 
> Ja, maar daar heb ik niet veel aan, osmose moet gebruikt worden (zou
> gebruikt moeten worden) door de mensen die mappen, die daarna kunnen
> controleren wat ze fout hebben gemapt.
> En daarbij komt dat het werkt in Frankrijk en Nederland, maar
> daarbuiten heb ik nog geen zinnige resultaten gezien.
> En ten 2e gaat het me om fouten in de spelling van kernwoorden. Als
> iemand wikkipedia schrijft, of wikipadia dan is dat geen osmosefout,
> maar ik kan er niets mee want ik zoek naar juist geformatteerde
> links. 
> Zo ook bij websites. Een webadres begint met http:// of zonder dat,
> maar http:/ is fout.
> En het is onmogelijk om op alle mogelijk spel en structuurfouten te
> anticiperen.
> 
> 
> Een deel van de fouten ontstaat overigens doordat bv. een tag op een
> way of een relatie staat ipv. op een losse node. En omdat ik om bv.
> alle mogelijk vormen van een museum te vinden wel moet zoeken naar
> node/way/rel, krijg ik ook alle verkeerd (of dubbel) geplaatste
> wikipedia/websitelinks te zien.
> 
> 
> Kijk eens hier:
> http://mijndev.openstreetmap.nl/~marczoutendijk/taglocator/?map=tourism&zoom=17&lat=51.91319&lon=4.47294&layers=B000FTF
> 
> 
> en klik dan op de contour van museum Boijmans, dan zie je dat
> wikipedia aan de relation hangt. Sterker nog, alles van dat museum
> hangt aan die relation.
> Maar in Berlijn kwam ik een paar museum objecten tegen waarbij nodes,
> ways en relations allemaal met stukjes van dat museum herbergen, met
> soms dus ook verdubbelingen van  tags. 
> En bij de wikipedialinks ga ik ervan uit dat de taalcode ook wordt
> meegegeven, maar als dat niet zo is, dan ontstaat er dus een slechte
> link.
> 
> 
> Marc.
> 
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Taglocator met links

[Gertjan Idema]

Osmose (http://osmose.openstreetmap.fr) geeft een duidelijk overzicht
van verkeerde wikipedia tags.
Selecteer 'all severity' en 'wikipedia' om de wikipedia fouten te
vinden.

Gertjan

On Wed, 2014-12-24 at 19:20 +0100, Marc Zoutendijk wrote:

> Vandaag ook de wikipedialinks toegevoegd.
> 
> Omdat wikipedia verwijzingen in de tags niet eenvormig zijn opgenomen, kan 
> het resultaat soms merkwaardig/ongeldig zijn.
> Als je dat tegenkomt, wil je dat dan hier melden?
> En maak een permalink van de situatie om te verwijzen.
> 
> Prettige kerstdagen!
> 
> Marc.
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Taglocator

[Gertjan Idema]

Dat ziet er goed uit Marc!
Wat ik nog mis zijn klikbare links. Met name natuurlijk voor de website
en wikipedia tags. Dit zou bereikt kunnen worden door een xml bestand te
downloaden van overpass in plaats van een html bestand. Met behulp van
een xslt scriptje kan van het xml bestand weer een html tekst gemaakt
worden, maar dan met links voor de tags waar dat van toepassing is.
Ik heb een voorbeeld xslt scriptje geschreven. Dit scriptje maakt links
voor de volgende tags: wikipedia, website, url, twitter, mdb_id en
dhm_id

Gertjan


http://www.w3.org/1999/XSL/Transform";>


http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">

  
  OSM3S Response



POIs











   



http://www.openstreetmap.org/browse//








: 
 





Wikipedia: http://.wikipedia.org/wiki/

 




Website: 
 




Twitter: http://www.twitter.com/
 




URL: 
 




Molendatabase: http://www.molendatabase.nl/nederland/molen.php?nummer=
 




De hollandsche molen: http://www.molens.nl/site/dbase/molen.php?mid=
 







On Mon, 2014-12-22 at 15:47 +0100, Marc Zoutendijk wrote:

> Ik maakte er al eerder melding van, maar inmiddels is er al aardig wat
> veranderd en bijgekomen in de taglocator.
> 
> 
> 
> Er zijn nu twee versies:
> 
> 
> De basisversie:
> http://mijndev.openstreetmap.nl/~marczoutendijk/taglocator/
> 
> 
> 
> 
> De versie met namen:
> http://mijndev.openstreetmap.nl/~marczoutendijk/taglocator/tagnames.html
> 
> 
> Vooral handig om te zien wat er in je omgeving nog niet is getagd!
> Zoom in op je woonplaats en kies bv. shop uit het menu.
> Kies de winkels die je wilt zien (waarvan je weet dat ze er zijn) en
> wacht even af om te zien of ze ook op OSM tevoorschijn komen.
> Dat valt vaak nog behoorlijk tegen. Want er zijn nog veel plaatsen
> waar wel alle wegen tot in detail zijn terug te vinden, maar waar is
> de bakker?
> Waar de drogist? Waar de benzinepomp?
> 
> 
> Reacties graag weer hier.
> Maar lees ook de vele commentaren op het forum:
> 
> 
> http://forum.openstreetmap.org/viewtopic.php?id=28807
> 
> 
> Marc.
> 
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Wikipedia

[Gertjan Idema]

On Sun, 2014-11-16 at 13:37 +0100, Sebastiaan Couwenberg wrote:

> On 11/16/2014 12:08 PM, Gertjan Idema wrote:
> > Waar ik zelf nog niet helemaal uit ben, is hoe je de wikipedia pagina's
> > van plaatsen in Friesland zou moeten taggen. Zelf heb ik voor de
> > gemeentes wikipedia=nl:... gebruikt en ik zag dat Bas dat voor de
> > woonplaatsen ook doet. Maar als je de regels strikt zou naleven, zou je
> > misschien wikipedia:fy moeten gebruiken. In België gebruiken ze
> > wikipedia:fr voor Luik, wikipedia:de voor Eupen en wikipedia:nl voor
> > Antwerpen.
> 
> Ik laat het aan de Friezen over om wikipedia:fy tags toe te voegen zoals
> ze ook doen met name:fy :)
> 

Ik had mijn bericht niet goed geformuleerd. De tags in België zijn
wikipedia=fr:Liège, wikipedia=de:Eupen en wikipedia=nl:Antwerpen. Voor
de plaatsen in Friesland zou dat dus misschien wikipedia:fy=Drachten
etc. moeten zijn. Maar dat laat ik ook graag aan de Friezen over.

Gertjan
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Wikipedia

[Gertjan Idema]

Ronald,

Ik zal Warmond even als voorbeeld gebruiken
De hoofdtag voor wikipedia is voor warmond: wikipedia=nl:Warmond. De
taal prefix is die van het land waarin de tag zich bevind, dus in het
geval van Warmond. De tag verwijst naar
http://nl.wikipedia.org/wiki/Warmond. In de meeste gevallen is dat
voldoende, omdat op de Nederlands wikipedia verwijzingen staan naar
andere talen. Als het om de een of andere reden gewenst zou zijn om
bijvoorbeeld de Albanese wiki pagina over Warmond toe te voegen, dan
gebruik je daar de tweede vorm: wikipedia:sq=Warmond. Omdat in dit geval
de taal in de key verwerkt zit, is het mogelijk om meerder van dit type
tags toe te voegen waar de basis wikipedia tag maar 1 waarde kan
bevatten.

Hier is wat de openstreetmap wiki
(http://wiki.openstreetmap.org/wiki/Key:wikipedia) hier over zegt:

Secondary languages
In almost all cases, a single wikipedia tag as described above is
sufficient. Data users can access articles in other languages where
available using Wikipedia's interlanguage links. If interlanguage links
are missing, this should usually be fixed within wikipedia.

One example where it is appropriate to provide additional explicit links
to articles in secondary languages is where the subject is included in
an article on a broader subject in the secondary language, for example
to wikipedia:en=Museums in Paris to the English article which provides
the best article for the particular museum in France, or
wikipedia:fr=places of worship in London which is the best article in
French for a particular church in London. In another example the
structure of subjects in articles cannot be matched 1:1 with
interlanguage links (or maybe there are several articles for the same
object). In these circumstances use the format wikipedia:lang=page title
for the secondary languages.

Waar ik zelf nog niet helemaal uit ben, is hoe je de wikipedia pagina's
van plaatsen in Friesland zou moeten taggen. Zelf heb ik voor de
gemeentes wikipedia=nl:... gebruikt en ik zag dat Bas dat voor de
woonplaatsen ook doet. Maar als je de regels strikt zou naleven, zou je
misschien wikipedia:fy moeten gebruiken. In België gebruiken ze
wikipedia:fr voor Luik, wikipedia:de voor Eupen en wikipedia:nl voor
Antwerpen.

Gertjan

On Sat, 2014-11-15 at 17:09 +0100, Ronald Stroethoff wrote:

> Ik zie dat iemand druk bezig is met het maken van links naar wikipedia.
> De gebruikte manier is:
> wikipedia=nl:Warmond
> Op de website:
> http://wiki.openstreetmap.org/wiki/Key:wikipedia
> worden twee manieren genoemd:
> wikipedia=en:St Paul's Cathedral
> en
> wikipedia:en=Museums in Paris
> 
> vooral bij grotere plaatsen en toeristische plekken is de kans groot dat er 
> wikipedia-pagina´s in meerdere talen zijn.
> Ik heb al wereldwijde edits gezien waarbij een locatie een hele rits pagina
> ´s had, en die dus vervangen door 1 pagina.
> 
> Graag hoor ik hoe we hiermee moeten omgaan?
> 
> Ronald
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Wijken in Nederland

[Gertjan Idema]

Alle wijken en buurten vind je hier:
http://www.cbs.nl/nl-NL/menu/themas/dossiers/nederland-regionaal/links/2013-buurtkaart-shape-versie-1-el.htm

Gertjan

On Thu, 2014-10-16 at 17:03 +0200, Pander OpenTaal wrote:

> In welke export zijn die namen te vinden om te kijken of onze
> spellingcontrole er geschikt voor is?
> 
> On 10/10/2014 03:13 PM, Minko wrote:
> > Als de exacte grenzen bekend zijn, zou je ook de wijkgrenzen kunnen 
> > invoeren mbv multipolygoon relaties die getagd zijn met 
> > boundary=administrative en admin_level=11
> > Zie http://forum.openstreetmap.org/viewtopic.php?id=18168
> > De wijknamen blijken echter niet meer op de osm.org kaart te worden 
> > gerenderd (was voorheen nog wel het geval).
> > 
> > ___
> > Talk-nl mailing list
> > Talk-nl@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-nl
> > 
> 
> 


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Donderdag mappersbabbel Amsterdam

[Gertjan Idema]

Ik ben helaas verhinderd.

Prettige avond morgen.

Gertjan

On Wed, 2014-02-19 at 10:50 +0100, Floris Looijesteijn wrote:
> Hallo!
> 
> 
> Beetje late aankondiging maar morgen (donderdag de 20e) is er weer een
> Mappersbabbel in Amsterdam.
> 
> 
> Aanmelding via meetup.com of anders hier wordt op prijs gesteld zodat
> we een goeie tafel kunnen kiezen. 
> 
> 
> 
> http://www.meetup.com/AmsGeoDrinks/events/165401792/
> 
> 
> 
> Vaste tijd en plaats: 19:00 bij Kaptein Zeppo's aan het 'Gebed Zonder
> End' in het centrum van Amsterdam.
> 
> 
> Groet en misschien tot morgen!
> Floris Looijesteijn
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Fout in gemeentegrens bij Haarlem door BAG import

[Gertjan Idema]

@Gert-Jan (met streepje en hoofdletter J)
Hiermee slinger je een hele nieuwe discussie aan ;-)

Nu hij getagd met name=Spaarndam en alt_name='Spaarndam gem. Haarlem'.
In mijn ogen zou dat op zijn minst official_name='Spaarndam gem.
Haarlem' moeten zijn.
Vervolgens kan je je af vragen of name='Spaarndam gem. Haarlem' en
short_name=Spaarndam niet beter zou zijn.
Het zelfde geldt voor straatnamen. 'Burg. Reigerstraat' of 'Burgemeester
Reigerstraat'.

Gertjan (zonder streepje of spatie en met kleine letter j) 

On Tue, 2014-01-14 at 23:31 +0100, Gert-Jan van der Weijden wrote:
> De woonplaats in de gemeente Haarlemse deel heet ook officieel
> “Spaarndam gem. Haarlem”, dus de woonplaatsnamen van de 2 delen van
> Spaardam zijn verschillend.
> 
>  
> 
> Gert-Jan (met streepje)
> 
>  
> 
> Ps. Ook leuk: sinds gisteren bestaat de woonplaats Amsterdam uit 2
> losse delen: het “oude” Amsterdam en het voormalige
> Amsterdam-Zuidoost. 
> 
>  
> 
>  
> 
>  
> 
> 
> Van: Gertjan Idema [mailto:g.id...@zonnet.nl] 
> Verzonden: dinsdag 14 januari 2014 23:16
> Aan: talk-nl@openstreetmap.org
> Onderwerp: Re: [OSM-talk-nl] Fout in gemeentegrens bij Haarlem door
> BAG import
> 
> 
> 
>  
> 
> Het probleem bij Spaarndam is, dat het uit 2 delen bestaat. Een deel
> in de gemeente Haarlem en een deel in de gemeente Haarlemmerliede en
> Spaarnwoude.
> Blijkbaar kan Keepright niet goed tegen twee administratieve gebieden
> met de zelfde naam op het zelfde level die aan elkaar grenzen.
> 
> Gertjan
> 
> On Tue, 2014-01-14 at 19:53 +0100, Sebastiaan Couwenberg wrote: 
> 
> 
>  
> On 01/14/2014 07:34 PM, Léon Tebbens wrote:
> > De gemeentegrens tussen Haarlem en Spaardam geeft foutmeldingen in 
> > Keepright: http://keepright.ipax.at/report_map.php?schema=90&error=45475266 
> > . Ik kom er niet achter wat het probleem is. Lijkt te komen door de BAG 
> > import.
> > 
> > Iemand een idee wat hier mis is?
>  
> KeepRight kan niet goed overweg met boundaries, wanneer KeepRight klaagt
> over een boundary is het verstandig om OSMI te raadplegen of de
> multipolygon ook invalid is of dat er een invalid geometry gerapporteerd
> word.
>  
> 999 van de 1000 keer zijn de boundary split warnings in KeepRight
> onterecht, en is de boundary correct.
>  
> Op het punt in kwestie komen 3 woonplaatsen en 3 gemeenten samen, alle 6
> deze relaties zijn gewoon valid. Haal ze maar eens door de JOSM
> validator en relation anaylizer.
>  
> Mvg,
>  
> Bas
>  
> 
> 
>  
> 
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Fout in gemeentegrens bij Haarlem door BAG import

[Gertjan Idema]

Het probleem bij Spaarndam is, dat het uit 2 delen bestaat. Een deel in
de gemeente Haarlem en een deel in de gemeente Haarlemmerliede en
Spaarnwoude.
Blijkbaar kan Keepright niet goed tegen twee administratieve gebieden
met de zelfde naam op het zelfde level die aan elkaar grenzen.

Gertjan

On Tue, 2014-01-14 at 19:53 +0100, Sebastiaan Couwenberg wrote:

> On 01/14/2014 07:34 PM, Léon Tebbens wrote:
> > De gemeentegrens tussen Haarlem en Spaardam geeft foutmeldingen in 
> > Keepright: http://keepright.ipax.at/report_map.php?schema=90&error=45475266 
> > . Ik kom er niet achter wat het probleem is. Lijkt te komen door de BAG 
> > import.
> > 
> > Iemand een idee wat hier mis is?
> 
> KeepRight kan niet goed overweg met boundaries, wanneer KeepRight klaagt
> over een boundary is het verstandig om OSMI te raadplegen of de
> multipolygon ook invalid is of dat er een invalid geometry gerapporteerd
> word.
> 
> 999 van de 1000 keer zijn de boundary split warnings in KeepRight
> onterecht, en is de boundary correct.
> 
> Op het punt in kwestie komen 3 woonplaatsen en 3 gemeenten samen, alle 6
> deze relaties zijn gewoon valid. Haal ze maar eens door de JOSM
> validator en relation anaylizer.
> 
> Mvg,
> 
> Bas
> 


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] That Shouldn't Be Possible™ coverage extended to Benelux

[Gertjan Idema]

Goedemorgen Robert.

That's a great tool you built!
>From now on I'll have to pay attention where I ride my bike ;-) As you
might know, dutch cyclists ride their bike everywhere no matter whether
it should or shouldn't be possible.
But we (OSM mappers) always stick to the rules of course, so for us It's
a wonderful addition to our toolbox.  

Thanks for sharing this with us.

Gertjan Idema

 
On Thu, 2013-11-21 at 21:44 +, Robert Scott wrote:

> Goedenavond.
> 
> (there - that should mask my linguistic failures enough for me to fall back 
> into english now)
> 
> My GPS trace analyzer, That Shouldn't Be Possible™ has recently extended its 
> reach beyond the british isles to cover benelux too.
> 
> Its purpose? To accept a GPS trace of a drive/cycle you've gone for, analyze 
> the journey against the routable OSM database and, if appropriate, say "That 
> Shouldn't Be Possible". Used like this, it can find quite a lot of routing 
> problems or road segments missing from the database.
> 
> It can also be used to take the hard work out of checking the OSM database 
> against your trace after a long journey by flagging up sections that don't 
> quite agree with OSM.
> 
> Not quite sure whether you've got that complex junction interlinked and 
> tagged right? Have a gps trace or two that traverses it? That Shouldn't Be 
> Possible might be able to help you.
> 
> An (extra special dutch) example analysis result can be seen here[1]: I've 
> left a nice great big error (visible as a spike in the plot) in the middle of 
> it as an example where the trace seems to traverse what's marked as a path.
> 
> I've written a lot more about it on the wiki[2], so I'm not going to 
> duplicate all that blather here. It's still in what I would call a prototype 
> stage, but it works surprisingly well for "motorcar" traces (less so for 
> bicycle so far, though I would say that's largely the fault of OSRM's bicycle 
> profile). Even so[3] I encourage mappers to try it out[4] on one of their 
> traces.
> 
> 
> robert.
> 
> [1] http://ris.dev.openstreetmap.org/tsbp-proto/779918/2/2/
> [2] http://wiki.openstreetmap.org/wiki/That_Shouldnt_Be_Possible
> [3] Especially so - I need testers.
> [4] http://ris.dev.openstreetmap.org/tsbp-proto/
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] nationaalgeoregister WFS service query

[Gertjan Idema]

Na wat puzzelen, heb ik het voor elkaar.
In de bijlage een html bestand dat drie open layers lagen produceert:
- Osm mapnik als achtergrond.
- Gemeentegrenzen (van
http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs)
- Woonplaatsgrenzen (van
http://geodata.nationaalgeoregister.nl/bagviewer/wfs)

Opvallend is, dat de bagviewer laag werkt zonder de outputFormat: 'GML2'
toevoeging.

Verdere voorwaarde is wel dat je de proxy-host goed geconfigureerd hebt.
Zie hiervoor:
http://www.techrepublic.com/blog/diy-it-guy/diy-enable-cgi-on-your-apache-server/

Het proxy.cgi script vind je hier:
http://trac.osgeo.org/openlayers/browser/trunk/openlayers/examples/proxy.cgi?format=txt
Dit script moet je een klein beetje aan passen, door op regel 18 bij
allowedHosts 'geodata.nationaalgeoregister.nl' toe te voegen.
Als je dat vergeet, krijg je een 'bad gateway' foutmelding.

Houdt er wel rekening dat het even kan duren voor de data geladen is.
Met name de woonplaats grenzen.
Ook vermoed ik, dat door het gebruik van de proxy-host, alle data via
jouw server naar de client gaat. Als je een beperkt aantal GB per maand
hebt bij je provider, kan dat dus consequenties hebben.

Groeten, Gertjan 


On Wed, 2013-10-16 at 12:08 +0200, Just van den Broecke wrote:

> Ok, welkom in de wondere wereld van WFS en OGC-protocollen :-).
> Het voordeel (boven een expliciete API zoals OSM XAPI) is dat je maar 1 
> protocol spec (WFS) hoeft te kennen. Op grond van een URL zoals 
> geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs moet je alle 
> metadata (types etc) kunnen opvragen. Nadeel is dat WFS 
> "onhandig"/verbose/redundant in elkaar zit. Meestal 2 stappen om uit te 
> vinden welke parameters je nodig hebt:
> 
> GetCapabilities:
> http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs?service=WFS&request=GetCapabilities&version=1.1.0
> DescribeFeatureType:
> http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs?service=WFS&request=DescribeFeatureType&version=1.1.0
> 
> Vooral uit de laatste haal je (onderaan) dat de laagnaam 
> 'gemeenten_2012' en het geometrie-veld 'geom' moet zijn (bij jou stond 
> 'geometrie').
> 
> Op grond daarvan heb ik net geprobeerd een OL laag toe te voegen in een 
> viewer waar ik net aan werk (http://kadviewer.kademo.nl) en zie dat dit 
> werkt:
> 
>  new OpenLayers.Layer.Vector("Bestuurlijke Grenzen - Gemeenten (WFS)", {
>  strategies: [new OpenLayers.Strategy.BBOX()],
>  visibility: false,
>  styleMap: new OpenLayers.StyleMap(
>  {'strokeColor': '#22', 'fillColor': '#ee', 
> graphicZIndex: 1, fillOpacity: 0.6}),
>  protocol: new OpenLayers.Protocol.WFS({
>  version: '1.1.0',
>  outputFormat: 'GML2',
>  srsName: 'EPSG:28992',
>  url: 
> http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs?,
>  featureType: "gemeenten_2012",
>  featureNS: "http://bestuurlijkegrenzen.geonovum.nl";,
>  geometryName: 'geom'
>  })
>  })
> 
> Gotcha: er zit een al 2 jaar bekend probleem in PDOK (GeoServer) WFS bij 
> gebruik van WFS 1.1.0: je krijgt standaard GML 3.1.1 output terug, maar 
> daarin zitten 'null' namespaces. Dat weten ze daar ook al 2 jaar, maar 
> heeft blijkbaar geen prio. Daarom als je outputFormat='GML2' opgeeft, 
> gaat het goed. Je kunt ook version: 1.0.0 (default) opgeven dan krijg je 
> standaard GML2 terug. Je kunt zelfs outputFormat=json of zelfs SHAPE-ZIP 
> opvragen...Wie volgt dit nog ;-)?
> 
> Goed, ja ik ben deze dagen, vaak knarsetandend, met WFS bezig, dus 
> "leuk" dit voorbij te zien komen. Overigens kan de 500 error goed met je 
> proxy-instelling, nodig bij OpenLayers+WFS, te maken hebben...
> 
> groet!
> 
> Just
> 
> 
> 
> On 16-10-13 09:20, Christ van Willegen wrote:
> > 2013/10/16 nouwsfam :
> >>
> >> "NetworkError: 500 Internal Server Error -
> >> http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs";
> >>
> >> en de foutmelding van de WFS server is nu
> >>
> >> "Reload the page to get source for:
> >> http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs";
> >
> > Dat is niet de foutmelding van de WFS server, maar FireBug toont daar
> > deze tekst...
> >
> > Die 'internal server error' is het probleem, maar dan krijg je ook,
> > over het algemeen, _geen_ data terug...
> >
> > Christ van Willegen
> >
> 
> 


Title: Bestuurlijke grenzen




	
	


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Vertaling van OSM labelnamen

[Gertjan Idema]

Vreemd. Als ik in Firefox bij Edit->Preferences->Languages Nederlands
bovenaan zet, krijg ik meteen de site in het Nederlands.
Bij Chromium werkt het net zo, via Settings->Show advanced
settings->Languages.

Gertjan


On Mon, 2013-10-07 at 11:41 +0200, Pander OpenTaal wrote:

> On 2013-10-06 16:54, Marc Gemis wrote:
> > 2013/10/6  :
> >> Hoi allemaal,
> >>
> >> Dit is mijn OpenTaalgeweten dat de kop op steekt; is er een Nederlandse
> >> versie van OSM en van haar online editors? Zijn er i18n-bestanden voor
> >> beschikbaar? Ik kan me herinneren dat er wel vertaalinitiatieven zijn
> >> geweest maar geen idee hoe die aan te zetten. Preferred language 'nl' in
> >> profile settings OSM gaf geen verschil.
> >>
> >> Groeten,
> >>
> >> Pander
> >>
> > 
> > Onlangs schreef Gilbert dit op de Belgische mailing list
> > 
> > Ik heb net een nieuwe versie van de NL vertaling van de Browsing wiki
> > pagina gemaakt (http://wiki.openstreetmap.org/wiki/NL:Browsing). Heeft
> > er iemand tijd en zin om eens na te kijken of er geen taalfouten,
> > moeilijke te snappen uitleg of andere onzin in staat ?
> 
> ik heb een paar foutjs verbeterd
> 
> > 
> > en dit
> > 
> > 
> > bedankt voor de moeite. En ik heb ook iets bijgeleerd. Ik wist niet
> > dat OSM ook in het Nederlands kon. Ik had in mijn profiel EN als
> > eerste taal in het rijtje staan - zonder mij te realiseren dat die
> > volgorde belang heeft - en kreeg bijgevolg de OSM interface in het
> > Engels.
> > Het is natuurlijk een kwestie van gewoonte. Ik werk altijd in het EN
> > met de computer. NL of eender welke andere taal op een computer doet
> > voor mij altijd wat onwennig aan...
> 
> Ik werk ook met alle software in het Engels (voor wie dat nog meer doet
> is https://github.com/PanderMusubi/locale-en-nl vast handig).
> 
> Helaas, nl vooraan in languages zetten in mijn profiel heeft geen effect
> in Firefox of Chromium. Ik zie dat je er alleen nl neer moet zetten, als
> er nog ;en staat werkt het niet. Is dit conform de requirements? Kan me
> voorstellen dat het lijstje ruimte geeft aan een fall back taal
> 
> > 
> > 
> > 
> > Dus er is wel degelijk een Nederlandse versie aanwezig, je moet enkel
> > je browser wijsmaken dat Nederlands in de eerste plaats komt.
> > 
> > Ik meen ook ooit op deze lijst gelezen te hebben dat iD vertaald is in
> > het Nederlands.
> > 
> > Ik hoop dat dit je verder helpt
> > 
> > groeten
> > 
> > m
> > 
> > ___
> > Talk-nl mailing list
> > Talk-nl@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-nl
> > 
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] BAG gegevens Re: OSM Navigatieapparatuur

[Gertjan Idema]

On Wed, 2013-05-29 at 14:29 +0200, Maarten Deen wrote:

> On 2013-05-29 14:05, Gertjan Idema wrote:
> > On Wed, 2013-05-29 at 11:54 +0200, Maarten Deen wrote:
> 
> >  Een heel goed voorbeeld dat het niet altijd mogelijk is om adressen
> > aan panden te knopen zie je bij Passage de Pit in Panningen. Dit is
> > één gebouw met de volgende adressen:
> >  Raadhuisstraat 4-86 (5981BG)
> >  Markt 30-44 (5981AP)
> >  Raadhuisplein 2-4 (5981AT)
> >  Passage de Pit 2-7 (5981CS)
> 
> Dat soort dingen zul je inderdaad altijd hebben bij hoekhuizen en 
> etagewoningen.
> Ik zie wel dat de BAG een voorkomend probleem oplost: waar moet je bij 
> flatgebouwen de huisnummers taggen: op de fysieke locatie of bij de 
> (communale) ingang? De BAG doet het dus bij de ingang. Ik zal eens 
> kijken of dat de enige ingang daar is, ik dacht dat er nog een was.

Dat wisselt per gemeente. BAG stelt alleen dat de huisnummers binnen de
contouren van het pand moeten liggen.
Hier kan je zien dat dat ruim geïnterpreteerd wordt:
http://www.openstreetmap.org/?lat=52.08095&lon=5.124964&zoom=18&layers=M



> Maar die site van die bagviewer is ook een goede. Daar kun je ook veel 
> mee (als in: gewoon overtrekken).
> 
> >> Is het mogelijk iets te maken voor mijn gemeente (OSM file of wat dan
> >> ook) waar ik min of meer de data van kan "overtrekken"? Veel anders 
> >> dan
> >> hoe ik het nu doe (met huisnummers die ik opschrijf als ik er langs
> >> loop) kan het niet zijn. Het scheelt me tenminste wel de tijd die ik
> >> moet besteden aan alle huisnummers langslopen.
> >  Wel minder goed voor je conditie ;-), maar ten eerste kan je de
> > huisnummers van de BAG viewer halen (zie link hierboven).
> >  Daarnaast heb ik zelf een tool waarmee ik BAG data uit een lokale
> > database kan omzetten naar een OSM bestand.
> >  Ik zal je bestanden voor Panningen en Helden opsturen.
> 
> Bedankt daarvoor.

Graag gedaan

> >  P.S. Staat Helden echt zo vol met hekjes?
> 
> Voorbeeld? Bedoel je misschien de erfafscheidingen die ik op sommige 
> plaatsen heb ingetekend? Ik weet ook niet of dat zo'n goed idee was 
> (alhoewel dat in achtertuinen wel altijd hekken of hagen zijn).

Wat ik zag was barrier:fence, ook waar het in werkelijkheid heggen zijn.
Beetje vreemd ook dat ze dwars door de huizen lopen. Op de Mapnik kaart
ziet het eruit alsof het kadastrale percelen zijn.

Gertjan

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] BAG gegevens Re: OSM Navigatieapparatuur

[Gertjan Idema]

On Wed, 2013-05-29 at 14:26 +0200, Jo wrote:

> Ik kan niet beloven dat ik er tijd voor heb (ben al wat teveel hooi op
> m'n vork aan het nemen), maar ik zou hier wel eens naar willen kijken.

Als je mee wilt denken graag.

> Waar kan ik de adresgegevens voor 1 gemeente afhalen als SHP of WFS?
> Of staan ze in een ander formaat?
> 

De URL van de WFS server is
http://geodata.nationaalgeoregister.nl/bagviewer/wfs
De feature voor de adressen is 'verblijfsobject'

Met feature 'woonplaats' kan je eventueel een polygoon van een
woonplaats opvragen 



> De gebouwen zitten al in OSM, vermoed ik?


De BAG gebouwen zitten nog niet in OSM. Wat er nu in OSM zit zijn
huizenblokken uit de 3dshapes import. Deze zijn minder gedetailleerd.


> 
> Polyglot
> 
> 
> Op 29 mei 2013 11:21 schreef Gertjan Idema  het
> volgende:
> 
> Mijn werk aan de import van BAG data staat inderdaad op een
> wat lager pitje. Dat komt deels door minder tijd en ook
> doordat ik me de laatste tijd wat minder goed kan
> concentreren.
> 
> Het gemis aan adresgegevens in OSM duikt wel steeds vaker op
> in discussies.
> Misschien moeten we toch eens overwegen om eenmalig een import
> van adressen uit de BAG (panden is een ander v verhaal) uit te
> voeren en tijdelijk voor lief te nemen dat er soms dubbele
> adressen in de database staan.
> Daarna kunnen we scripts gebruiken om dubbelen en andere
> onvolkomenheden op te sporen en te corrigeren. En ook om
> nieuwe adressen (en panden) toe te voegen.
> 
> Nadelen van deze methode:
> - Routeringsalgorithmen  kunnen soms moeite hebben met dubbele
> adressen.
> - Het kan er rommelig uitzien in de huidige rendering:
> 
> http://www.openstreetmap.org/?lat=52.08095&lon=5.124964&zoom=18&layers=M
>     
> Gertjan
> 
> 
> 
> On Wed, 2013-05-29 at 09:41 +0200, Minko wrote: 
> 
> > Gertjan Idema was bezig met een script om de BAG data eenvoudig te 
> kunnen importeren in JOSM.
> > Ik weet niet hoever het daarmee staat. Op het OSM forum zijn we er 
> ook mee bezig, maar het project staat een beetje op een laag pitje: 
> http://forum.openstreetmap.org/viewtopic.php?pid=336687#p336687
> >  
> > > De gegevens moeten wel in OSM zitten willen andere 
> kaartgebruikers er
> > > voordeel van hebben.
> > 
> > Omdat er weinig schot in de zaak zit hebben we de BAG gegevens maar 
> achteraf gemixed met de OSM data tbv onze Garmin kaarten. Het is wel beter om 
> het in OSM te voeren zodat de straatnamen van het BAG beter gematched kunnen 
> worden met die in OSM.
> > 
> > ___
> > Talk-nl mailing list
> > Talk-nl@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-nl
> 
> 
> 
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl
> 
> 
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] BAG gegevens Re: OSM Navigatieapparatuur

[Gertjan Idema]

On Wed, 2013-05-29 at 11:54 +0200, Maarten Deen wrote:

> On 2013-05-29 11:21, Gertjan Idema wrote:
> > Mijn werk aan de import van BAG data staat inderdaad op een wat lager
> > pitje. Dat komt deels door minder tijd en ook doordat ik me de laatste
> > tijd wat minder goed kan concentreren.
> > 
> >  Het gemis aan adresgegevens in OSM duikt wel steeds vaker op in 
> > discussies.
> >  Misschien moeten we toch eens overwegen om eenmalig een import van
> > adressen uit de BAG (panden is een ander v verhaal) uit te voeren en
> > tijdelijk voor lief te nemen dat er soms dubbele adressen in de
> > database staan.
> >  Daarna kunnen we scripts gebruiken om dubbelen en andere
> > onvolkomenheden op te sporen en te corrigeren. En ook om nieuwe
> > adressen (en panden) toe te voegen.
> 
> Ik ben niet direkt een tegenstander van een automatische import (het 
> geeft natuurlijk lekker snel resultaat) maar ik ben er wel voorstander 
> van om het goed te doen. En daarmee bedoel ik dus de bestaande gebouwen 
> opdelen in de afzonderlijke gebouwen en de huisnummers in de area van 
> het gebouw te zetten i.p.v. afzonderlijke nodes met huisnummers neer te 
> zetten.
> Vergelijk waar ik in mijn woonplaats mee bezig ben:
> <http://www.openstreetmap.org/?lat=51.318867&lon=5.995507&zoom=18&layers=M>


Ik denk dat er meerdere wensen zijn:
Er is de wens om de woonblokken uit de 3d shapes import op te splitsen
in individuele panden.
Er is de wens om OSM te voorzien van adressen ten bate van
routeplanners.
Er is de wens om daar waar mogelijk de adressen aan de panden te knopen.
Er is de wens in de toekomst wijzigingen in panden en adressen te kunnen
bijwerken OSM.
etc.

Ik vraag mij af of het allemaal in een keer moet, of dat het ook in
stappen kan. Op het moment dat je adressen zoveel mogelijk aan panden
wilt knopen, is het nodig om panden en adressen tegelijk in te voeren.
Omdat panden complexer zijn dan adressen (automatische import eigenlijk
niet mogelijk), betekent dat dat het nog lang kan duren voordat de
database voorzien is van alle adressen in Nederland.
In mijn ogen zijn de adressen waardevoller dan de panden. De
aanwezigheid van alle Nederlandse adressen in OSM biedt namelijk
mogelijkheden bieden voor allerlei op OSM gebaseerde applicaties. Dit
kan voor veel applicaties de overstap van Google naar OSM betekenen, OSM
in Nederland figuurlijk op de kaart zetten en daarmee ook weer nieuwe
vrijwilligers trekken.
Daarnaast staat in mijn ogen een  initiële import van alleen adressen
uit BAG de overige wensen niet in de weg. Als in een later stadium
individuele panden worden toegevoegd, kunnen de adressen alsnog worden
overgezet van een losse node naar een pand. Die voorziening staat al op
mijn wensenlijstje voor de Josm plug-in die ik aan het schrijven ben.

Een heel goed voorbeeld dat het niet altijd mogelijk is om adressen aan
panden te knopen zie je bij Passage de Pit in Panningen. Dit is één
gebouw met de volgende adressen:
Raadhuisstraat 4-86 (5981BG)
Markt 30-44 (5981AP)
Raadhuisplein 2-4 (5981AT)
Passage de Pit 2-7 (5981CS)

(Zie ook de BAG viewer: pdok.nl/bagviewer)




> Is het mogelijk iets te maken voor mijn gemeente (OSM file of wat dan 
> ook) waar ik min of meer de data van kan "overtrekken"? Veel anders dan 
> hoe ik het nu doe (met huisnummers die ik opschrijf als ik er langs 
> loop) kan het niet zijn. Het scheelt me tenminste wel de tijd die ik 
> moet besteden aan alle huisnummers langslopen.

Wel minder goed voor je conditie ;-), maar ten eerste kan je de
huisnummers van de BAG viewer halen (zie link hierboven).
Daarnaast heb ik zelf een tool waarmee ik BAG data uit een lokale
database kan omzetten naar een OSM bestand.
Ik zal je bestanden voor Panningen en Helden opsturen.

Gertjan

P.S. Staat Helden echt zo vol met hekjes?


> 
> Maarten
> 
> >  On Wed, 2013-05-29 at 09:41 +0200, Minko wrote:
> > 
> >> Gertjan Idema was bezig met een script om de BAG data eenvoudig te 
> >> kunnen importeren in JOSM.
> >> Ik weet niet hoever het daarmee staat. Op het OSM forum zijn we er 
> >> ook mee bezig, maar het project staat een beetje op een laag pitje: 
> >> http://forum.openstreetmap.org/viewtopic.php?pid=336687#p336687 [1]
> >> 
> >>> De gegevens moeten wel in OSM zitten willen andere kaartgebruikers 
> >>> er
> >>> voordeel van hebben.
> >> 
> >> Omdat er weinig schot in de zaak zit hebben we de BAG gegevens maar 
> >> achteraf gemixed met de OSM data tbv onze Garmin kaarten. Het is wel 
> >> beter om het in OSM te voeren zodat de straatnamen van het BAG beter 
> >> gematched kunnen worden met die in OSM.
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] BAG gegevens Re: OSM Navigatieapparatuur

[Gertjan Idema]

Mijn werk aan de import van BAG data staat inderdaad op een wat lager
pitje. Dat komt deels door minder tijd en ook doordat ik me de laatste
tijd wat minder goed kan concentreren.

Het gemis aan adresgegevens in OSM duikt wel steeds vaker op in
discussies.
Misschien moeten we toch eens overwegen om eenmalig een import van
adressen uit de BAG (panden is een ander v verhaal) uit te voeren en
tijdelijk voor lief te nemen dat er soms dubbele adressen in de database
staan.
Daarna kunnen we scripts gebruiken om dubbelen en andere onvolkomenheden
op te sporen en te corrigeren. En ook om nieuwe adressen (en panden) toe
te voegen.

Nadelen van deze methode:
- Routeringsalgorithmen  kunnen soms moeite hebben met dubbele adressen.
- Het kan er rommelig uitzien in de huidige rendering:
http://www.openstreetmap.org/?lat=52.08095&lon=5.124964&zoom=18&layers=M

Gertjan

On Wed, 2013-05-29 at 09:41 +0200, Minko wrote:

> Gertjan Idema was bezig met een script om de BAG data eenvoudig te kunnen 
> importeren in JOSM.
> Ik weet niet hoever het daarmee staat. Op het OSM forum zijn we er ook mee 
> bezig, maar het project staat een beetje op een laag pitje: 
> http://forum.openstreetmap.org/viewtopic.php?pid=336687#p336687
>  
> > De gegevens moeten wel in OSM zitten willen andere kaartgebruikers er
> > voordeel van hebben.
> 
> Omdat er weinig schot in de zaak zit hebben we de BAG gegevens maar achteraf 
> gemixed met de OSM data tbv onze Garmin kaarten. Het is wel beter om het in 
> OSM te voeren zodat de straatnamen van het BAG beter gematched kunnen worden 
> met die in OSM.
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Multi poligons

[Gertjan Idema]

Hoi Ronald,

De Josm plug-in 'utilsplugin2' heeft een functie 'Split object'. Hiermee
kan je een gebied splitsen.
In jouw voorbeeld selecteer je de multpolygoon en twee nodes aan beide
kanten van de ingang van de passantenhaven. Als je vervolgens op 'Object
splitsen' klikt, wordt het water opgesplitst in twee delen.

Het selecteren van de nodes kan je eenvoudiger maken met een filter
(bijvoorbeeld -natural=water) alles verbergen wat geen water is.

Gertjan

On Thu, 2013-04-04 at 21:23 +0200, Ronald Stroethoff wrote:

> St Niklaas wrote:
> 
> > Beste Ronald,Alleen al om de zaken uit elkaar te trekken of the
> > onderscheiden is een aparte los liggende polygoone nodig lijkt mij.Is er
> > dan een andere manier om bv water in een bos of park te isoleren ?Waarom
> > veroorzaakt dat hinder en waarbij ?Hendrik
> 
> Op deze plek:
> http://www.openstreetmap.org/?lat=52.2113&lon=4.57431&zoom=17&layers=M
> 
> Wilde ik enige verbeteringen aanbrengen, namelijk een stukje water bleek een 
> passantenhaventje te zijn en een ander stuk water heeft een eigen naam.
> 
> Hiervoor moest ik dus het water in stukken knippen.
> 
> Ik kwam daar meerdere problemen tegen
> 
> 1) stukken weiland lagen met de punten op de punten van het water waardoor 
> ze niet apart te selecteren zijn.
> 
> 2) bij het knippen begonnen verschillende relaties te protesteren.
> 
> ronald
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)

[Gertjan Idema]

Zie inline commentaar.

On Thu, 2013-02-28 at 01:46 +0100, Sebastiaan Couwenberg wrote:

> On 02/27/2013 09:34 PM, Gertjan Idema wrote:
> > On Sun, 2013-02-24 at 17:09 +0100, Sebastiaan Couwenberg wrote:
> > 
> >> Het is niet handig dat de ref:woonplaatscode van Putten is aangepast
> >> naar de code in de meest recente BAG zonder ook de geometrie aan te
> >> passen. De ref:woonplaatscode/name tuple hoorde bij de geometrie van het
> >> record in bag:extract WPL08082012, bij de aangepaste woonplaatscode
> >> zit ook een nieuwe geometrie van de woonplaats in bag:extract
> >> WPL08012013. Voor Putten er Nijkerk heb ik net ook de geometrie
> >> aangepast met de versie uit bag:extract WPL08012013.
> >>
> > 
> > Ik was me er niet van bewust dat je al zo ver was met de BAG
> > woonplaatsgrenzen. 
> 
> Dat is ook deels mijn schuld, ik heb er geen openbare progress report
> oid van bijgehouden zoals voor het Woonplaatsbesluiten project is gedaan.
> 
> http://wiki.openstreetmap.org/wiki/Bestaande_geodata_hergebruiken_woonplaatsbesluiten
> 
> Het is mijn bedoeling om een dergelijk overzicht te genereren met
> bijbehorende interactieve kaart voor de grenzen die in OSM geupdate
> kunnen worden met de meeste recente versie in de BAG.
> 
> Hier wil ik pas echt goed voor gaan zitten als ik klaar ben met alle
> woonplaatsgrenzen gelijk trekken met de inmiddels wat oude BAG, maar
> gezien de woonplaatsen niet zoveel aan verandering onderhevig zijn als
> de panden vind ik dat niet zo'n probleem. Voordat de grenzen met BAG
> data geupdate werden was er tijden weinig tot niets aangepast, we zijn
> er dus op vooruit gegaan qua actualiteit, maar nog niet helemaal
> volledig up-to-date.
> 
> In eerste instantie had ik mij ook voorgenomen om de procedure die ik
> volg bij het toevoegen en updaten van grenzen aan de BAGimport wiki
> pagina toe te voegen, maar ik twijfelde over het nut ervan. Het
> toevoegen van grenzen is een redelijk eenmalig proces, daarna zullen de
> bestaande grenzen aangepast worden. Tenzij er nog nieuwe woonplaatsen in
> het leven geroepen worden zal al het werk het updaten van bestaande
> grenzen omvatten. Het is leek mij nuttiger om dat proces te gaan
> documenteren wanneer alle ontbrekende grenzen waren toegevoegd. Daar is
> het nu dus wel tijd voor aan het worden, maar ik zal hoogst
> waarschijnlijk nog even procastinaten. Want ik wil mijn tijd nu nog even
> in de laatste 484 woonplaatsen steken.
> 

Dit lijkt mij inderdaad een eenmalige klus. Zou jammer zijn van je
energie om het uitgebreid te documenteren.

> >>> 2. 'Onlogische' woonplaatsnamen in de BAG:
> >>> Bij een aantal plaatsen heb ik er voor gekozen om de naam in OSM niet
> >>> aan te passen aan de officiële BAG namen. In plaats daarvan heb ik de
> >>> BAG namen in de 'alt_name' tag geplaatst. Aan het lijstje hieronder is
> >>> denk ik wel te zien waarom. (de tweede naam is de BAG naam):
> >>> "Alteveer""Alteveer gem Hoogeveen"
> >>> "Botlek""Botlek Rotterdam"
> >>> "De Hoef""de Hoef"
> >>> "De Lutte""de Lutte"
> >>> "Den Haag""'s-Gravenhage"
> >>> "De Woude""de Woude"
> >>> "Elst""Elst Ut"
> >>> "Europoort""Europoort Rotterdam"
> >>> "Hoogvliet""Hoogvliet Rotterdam"
> >>> "Maasvlakte""Maasvlakte Rotterdam"
> >>> "Pernis""Pernis Rotterdam"
> >>> "'s-Hertogenbosch""Den Bosch"
> >>> "Ursem""Ursem gem. S"
> >>> "Vondelingenplaat""Vondelingenplaat Rotterdam"
> >>
> >> Ik twijfelde welke tag hiervoor te gebruiken, official_name was
> >> misschien ook een optie gezien de Woonplaats als zodanig in de officiele
> >> bron staat. Maar alt_name is waarschijnlijk beter.
> > 
> > Bij http://wiki.openstreetmap.org/wiki/Key:official_name staat 'It has
> > been created for country names'. Er staat dus niet bij dat het niet voor
> > andere namen gebruikt mag worden. Ik neig er nu toch meer naar om
> > 'official_name' te gaan gebruiken. Zodra we het er over eens zijn,
> > kunnen we dit vermelden in de Nederlandse wiki.
> 
> Tsja, interpretatie van tags blijft een lastig issue.
> 
> Wat is de officiële naam van een woonplaats? Dat lijkt mij de naam die
> op off

Re: [OSM-talk-nl] OSM in RD tiles

[Gertjan Idema]

Ik heb de indruk dat gdal zelf ook coordinatensystemen bij houdt.
Op mijn systeem vind ik ze op 3 plaatsen:
/usr/share/gdal/1.8
/usr/share/gdal/1.9
/usr/share/gdal16
Geen idee of daar wat mee gedaan wordt.

Wel vond ik een handig commando:
gdalsrsinfo epsg:28992

Bij mij geeft dit:

PROJ.4 : '+proj=sterea +lat_0=52.156160 +lon_0=5.387639
+k=0.079 +x_0=155000 +y_0=463000 +ellps=bessel
+towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725
+units=m +no_defs '

OGC WKT :
PROJCS["Amersfoort / RD New",
GEOGCS["Amersfoort",
DATUM["Amersfoort",
SPHEROID["Bessel 1841",6377397.155,299.1528128,
AUTHORITY["EPSG","7004"]],

TOWGS84[565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725],
AUTHORITY["EPSG","6289"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4289"]],
PROJECTION["Oblique_Stereographic"],
PARAMETER["latitude_of_origin",52.156160],
PARAMETER["central_meridian",5.387639],
PARAMETER["scale_factor",0.079],
PARAMETER["false_easting",155000],
PARAMETER["false_northing",463000],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["X",EAST],
AXIS["Y",NORTH],
AUTHORITY["EPSG","28992"]]

Gertjan


On Sat, 2013-03-02 at 22:02 +0100, Peter Peterse wrote:

> Hallo,
> 
> het is een proj 4.7.1 zelf gebouwd. Een andere versie staat er niet op.
> Zoals te zien in mijn eerdere mail bevat deze wel de optie +towgs84=
> 
> locate epsg vond enkel dit bestand dat relevant was voor dit issue.
> 
> Groeten,
> Peter
> 
> 
> Op 2-3-2013 21:47, Cartinus schreef:
> > Hallo,
> >
> > Staat er niet ook nog een bestand /usr/share/proj/epsg op je computer?
> > Dat is waar dacht ik de meeste linux distributies het laten. De
> > standaard packages bevatten meestal versie 4.7.0 (of ouder) van proj en
> > daarin miste de +towgs84 parameter.
> >
> > m.v.g.,
> > Martijn
> >
> > On 03/02/2013 09:31 PM, Peter Peterse wrote:
> >> Hallo Gertjan,
> >>
> >> bedankt voor het antwoord. Het werkt. Zie resultaat
> >> <http://osm.peterse-uithuizen.com/~peter/2deMaasvlakte_in_RD_2.png>
> >> Echter begrijp ik het niet. In het bestand /usr/local/share/proj/epsg
> >> van proj zie ik:
> >> <28992> +proj=sterea +lat_0=52.156160 +lon_0=5.387639
> >> +k=0.08 +x_0=155000 +y_0=463000 +ellps=bessel +units=m
> >> +towgs84=565.2369,50.0087,465.658,-0.406857330322398,0.350732676542563,-1.8703473836068,4.0812
> >> +no_defs no_defs
> >> Deze bevat gelijke waarden als jij in het forum noemt.
> >> Een andere schuldige kan ik zo niet vinden.
> >>
> >> Nogmaals bedankt,
> >> Peter
> >>
> >>
> >> Op 2-3-2013 12:52, Gertjan Idema schreef:
> >>> Hallo Peter,
> >>>
> >>> Het lijkt er op de projectie parameters voor RD niet compleet zijn.
> >>> Dat geeft een afwijking van zo'n 100m naar het zuid-zuidwesten. In het
> >>> volgende forum artikel onder #7 vind je een mogelijke work-around:
> >>> forum.openstreetmap.org/viewtopic.php?id=12204
> >>>
> >>> Laat even weten of het werkt.
> >>>
> >>> Groeten, Gertjan
> >>>
> >>> On Fri, 2013-03-01 at 16:45 +0100, Peter Peterse wrote:
> >>>> Hallo allemaal,
> >>>>
> >>>> ik probeer de 2de maasvlakte in RD tiles weer te geven. Echter zie ik een
> >>>> verschil t.o.v. de officiele site:
> >>>> <http://www.openstreetmap.org/?lat=51.9777&lon=4.001&zoom=14&layers=M>
> >>>>
> >>>> Een screenshot van mijn lokale server is te vinden op:
> >>>> <http://osm.peterse-uithuizen.com/~peter/2deMaasvlakte_in_RD.png 
> >>>> <http://osm.peterse-uithuizen.com/%7Epeter/2deMaasvlakte_in_RD.png>>
> >>>>
> >>>> Tussen de weg en het strand bevind zich bij mij water. Ik heb de
> >>>> world_boundaries bijgewerkt en geherprojecteerd met de commando's:
> >>>>
> >>>> extent="225743.58199723 6343505.39917919 816703.80429861 
> >>>> 7125169.31386459"
> >>>> ogr2ogr -f "ESRI Shapefile" -s_srs EPSG:900913 -t_srs EPSG:${srs} \
> >>>>-spat ${extent}  builtup_area_28992.shp builtup_area.shp
> >>>> ogr2ogr -f "ESRI Shapefile" -s_srs EPSG:900913 -t_srs EPSG:${srs} \
> >>>>-spat ${extent}  processed_p_28992.shp processed_p.shp
> >>>> ogr2ogr -f "ESRI Shapefile" -s_srs EPSG:900913 -t_srs EPSG:${srs}  \
> >>>>-spat ${extent}  shoreline_300_28992.shp shoreline_300.shp
> >>>>
> >>>> Heeft iemand een idee wat er mis kan zijn?
> >>>>
> >>>> Alvast bedankt,
> >>>> Peter
> >>>>
> >>>>
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] OSM in RD tiles

[Gertjan Idema]

Hallo Peter,

Het lijkt er op de projectie parameters voor RD niet compleet zijn. Dat
geeft een afwijking van zo'n 100m naar het zuid-zuidwesten. In het
volgende forum artikel onder #7 vind je een mogelijke work-around:
forum.openstreetmap.org/viewtopic.php?id=12204

Laat even weten of het werkt.

Groeten, Gertjan

On Fri, 2013-03-01 at 16:45 +0100, Peter Peterse wrote:

> Hallo allemaal,
> 
> ik probeer de 2de maasvlakte in RD tiles weer te geven. Echter zie ik een
> verschil t.o.v. de officiele site:
> 
> 
> Een screenshot van mijn lokale server is te vinden op:
> 
> 
> Tussen de weg en het strand bevind zich bij mij water. Ik heb de
> world_boundaries bijgewerkt en geherprojecteerd met de commando's:
> 
> extent="225743.58199723 6343505.39917919 816703.80429861 7125169.31386459"
> ogr2ogr -f "ESRI Shapefile" -s_srs EPSG:900913 -t_srs EPSG:${srs} \
>-spat ${extent}  builtup_area_28992.shp builtup_area.shp
> ogr2ogr -f "ESRI Shapefile" -s_srs EPSG:900913 -t_srs EPSG:${srs} \
>-spat ${extent}  processed_p_28992.shp processed_p.shp
> ogr2ogr -f "ESRI Shapefile" -s_srs EPSG:900913 -t_srs EPSG:${srs}  \
>-spat ${extent}  shoreline_300_28992.shp shoreline_300.shp
> 
> Heeft iemand een idee wat er mis kan zijn?
> 
> Alvast bedankt,
> Peter
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)

[Gertjan Idema]

On Sun, 2013-02-24 at 17:09 +0100, Sebastiaan Couwenberg wrote:


> Het is niet handig dat de ref:woonplaatscode van Putten is aangepast
> naar de code in de meest recente BAG zonder ook de geometrie aan te
> passen. De ref:woonplaatscode/name tuple hoorde bij de geometrie van het
> record in bag:extract WPL08082012, bij de aangepaste woonplaatscode
> zit ook een nieuwe geometrie van de woonplaats in bag:extract
> WPL08012013. Voor Putten er Nijkerk heb ik net ook de geometrie
> aangepast met de versie uit bag:extract WPL08012013.
> 

Ik was me er niet van bewust dat je al zo ver was met de BAG
woonplaatsgrenzen. 

> > 2. 'Onlogische' woonplaatsnamen in de BAG:
> > Bij een aantal plaatsen heb ik er voor gekozen om de naam in OSM niet
> > aan te passen aan de officiële BAG namen. In plaats daarvan heb ik de
> > BAG namen in de 'alt_name' tag geplaatst. Aan het lijstje hieronder is
> > denk ik wel te zien waarom. (de tweede naam is de BAG naam):
> > "Alteveer""Alteveer gem Hoogeveen"
> > "Botlek""Botlek Rotterdam"
> > "De Hoef""de Hoef"
> > "De Lutte""de Lutte"
> > "Den Haag""'s-Gravenhage"
> > "De Woude""de Woude"
> > "Elst""Elst Ut"
> > "Europoort""Europoort Rotterdam"
> > "Hoogvliet""Hoogvliet Rotterdam"
> > "Maasvlakte""Maasvlakte Rotterdam"
> > "Pernis""Pernis Rotterdam"
> > "'s-Hertogenbosch""Den Bosch"
> > "Ursem""Ursem gem. S"
> > "Vondelingenplaat""Vondelingenplaat Rotterdam"
> 
> Ik twijfelde welke tag hiervoor te gebruiken, official_name was
> misschien ook een optie gezien de Woonplaats als zodanig in de officiele
> bron staat. Maar alt_name is waarschijnlijk beter.

Bij http://wiki.openstreetmap.org/wiki/Key:official_name staat 'It has
been created for country names'. Er staat dus niet bij dat het niet voor
andere namen gebruikt mag worden. Ik neig er nu toch meer naar om
'official_name' te gaan gebruiken. Zodra we het er over eens zijn,
kunnen we dit vermelden in de Nederlandse wiki.

> 
> Zien de OSM relations voor woonplaatsgrenzen met behulp van de
> ref:woonplaatscode en diens naam (name of alt_name) tag gekoppeld worden
> aan de records in de BAG is het van belang dat een van de twee tags
> (name of alt_name) overeen komen met de woonplaatsnaam in de BAG.
> 
> Alteveer is trouwens een leuke, daarvan bestaan woonplaatsgrenzen in
> meerdere gemeentes, en in meerdere provincies. Gelukkig hebben we nu de
> ref:woonplaatscode om de 4 verschillende Alteveers te kunnen onderscheiden.

Inderdaad. En er zijn ook nog genoeg namen die 3 of twee keer voorkomen.
Daarom vond ik 'Elst Ut', 'Ursem gem. S' en 'Alteveer gem Hoogeveen' ook
opvallende uitzonderingen.

> > Zoals ik in het onderwerp al vermeldde, betekent dit nog niet dat alle
> > woonplaatsgrenzen nu netjes op de zelfde plek liggen als in de BAG. Dat
> > is nog wel even werk.
> 
> Alleen de provincies Zuid-Holland, Utrecht, Flevoland en Noord-Holland
> moeten nog gelijkgetrokken worden met de BAG, de overige provincies heb
> ik reeds voltooid. Wel moet ik alles nog eens met de meest recente BAG
> vergeleken worden wanneer alle admin_level=10 grenzen in OSM op basis
> van de BAG zijn. Deze vergelijking zal geautomatiseerd worden, het
> gelijk trekken van de overige provincies is nog wat handwerk in JOSM.
> Maar met de Replace Geometry functie is het minder tijdrovend dan het
> volledig handmatig mergen van alle nodes wat ik voorheen deed.
> 

Goed werk! 

> Het nadeel is wel dat met het verschuiven van de nodes deze niet
> losgekoppeld worden van eventueel daaraan verbonden niet-boundary wegen.
> Hier heb ik nu ook een controle script voor die met behulp van een
> lokale OSM DB een rapportage maakt van alle niet-boundary wegen die
> verbonden zijn met een boundary. Het handmatig losknopen hiervan is ook
> nog best wat handwerk.
> 
> De Replace Geometry functie in JOSM koppelt verbonden wegen automatisch
> los, maar dat kan alleen als de OSM data ervan beschikbaar is. Op zich
> niet zo'n probleem, want met wat Overpass Queries is deze data ook zo op
> te halen, alleen kost het uitvoeren hiervan meer tijd dan ik op het
> downloaden van alle grenzen binnen een provincie wil wachten.

Is 'Download parent ways/relations' Ctrl+Alt-D hiervoor een optie, of
ook te traag?
Replace geometry kende ik niet, maar ga ik zeker onthouden. Ook voor de
BAG panden. 

> 
> Nu doe ik een controle achter af. Na het updaten van alle grenzen binnen
> een gemeente check of er nog niet-boundary ways aan de aangepaste
> boundary ways verbonden waren. En koppel deze los indien deze aanwezig
> waren.
> 
> Dat heb ik niet voor alle boundaries even secuur gedaan, waardoor er nog
> wat fouten in de voltooide provincies kunnen zitten. Deze zal ik ook
> allemaal nog corrigeren.
> 
> > Andere klussen:
> > Het gebruik van type=boundary/type=multipolygon nog niet consequent.
> > Volgens de Nederlandse conventie gebruiken we type=multipolygon. Op de
> > internationale site staat echter dat type=multipolygon verouder

[OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)

[Gertjan Idema]

Dankzij veel werk van vooral 'Sebastic' en 'It's so Funny', staan alle
officiële woonplaatsen nu in de OSM database. Dit zijn de boundaries met
admin_level=10.
Zelf heb ik de ontbrekende woonplaatscodes toegevoegd en de
woonplaatsnamen vergeleken met de BAG data van 8-1-2013. In twee
situaties kan er een afwijking zijn t.o.v. de BAG:

1. Dubbele woonplaatscodes in de BAG:
 In overgangssituaties kan het voorkomen dat woonplaatsen in de BAG
tijdelijk met oude en nieuwe woonplaatscodes voorkomen. Tijdelijk is
hier een ruim begrip, want het kan meer dan een jaar zijn. In deze
gevallen heb ik de nieuwste woonplaatscode in OSM gezet. 
Het gaat hier om: Apeldoorn, Leimuiden, Oudkarspel, Putten en
Rijpwetering.

2. 'Onlogische' woonplaatsnamen in de BAG:
Bij een aantal plaatsen heb ik er voor gekozen om de naam in OSM niet
aan te passen aan de officiële BAG namen. In plaats daarvan heb ik de
BAG namen in de 'alt_name' tag geplaatst. Aan het lijstje hieronder is
denk ik wel te zien waarom. (de tweede naam is de BAG naam):
"Alteveer""Alteveer gem Hoogeveen"
"Botlek""Botlek Rotterdam"
"De Hoef""de Hoef"
"De Lutte""de Lutte"
"Den Haag""'s-Gravenhage"
"De Woude""de Woude"
"Elst""Elst Ut"
"Europoort""Europoort Rotterdam"
"Hoogvliet""Hoogvliet Rotterdam"
"Maasvlakte""Maasvlakte Rotterdam"
"Pernis""Pernis Rotterdam"
"'s-Hertogenbosch""Den Bosch"
"Ursem""Ursem gem. S"
"Vondelingenplaat""Vondelingenplaat Rotterdam"

Zoals ik in het onderwerp al vermeldde, betekent dit nog niet dat alle
woonplaatsgrenzen nu netjes op de zelfde plek liggen als in de BAG. Dat
is nog wel even werk.

Andere klussen:
Het gebruik van type=boundary/type=multipolygon nog niet consequent.
Volgens de Nederlandse conventie gebruiken we type=multipolygon. Op de
internationale site staat echter dat type=multipolygon verouderd is. Dat
is nogal verwarrend. Huidige status: multipolygon=2173x, boundary=327x

Het komt nog regelmatig (341x) voor dat de 'role' niet is ingevuld in de
relaties. Hier ga ik binnenkort nog wat aan bijwerken.

Sebastiaan is bezig met scripting voor het vergelijken van geometrien
van de grenzen.

Gertjan Idema



___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

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

[Gertjan Idema]

Hoi Floris,

Ik kom naar de nieuwjaarsborrel en zal m'n laptop meenemen. Een
demonstratie is dan geen probleem.

Gertjan

On Thu, 2013-01-10 at 12:19 +0100, Floris Looijesteijn wrote:

> klinkt erg mooi!
> 
> 
> 
> kom je naar de nieuwjaarsborrel? en zo ja, zou je dit dan kunnen
> demonstreren?
> 
> 
> gr,
> floris
> 
> 
> 2013/1/9 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  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.
> >

Re: [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  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@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

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

[Gertjan Idema]

Ik heb er even naar gekeken, maar niet concreets kunnen vinden over wat
voor informatie aangeboden gaat worden en in wat voor formaat. Volgende
week maar eens kijken of er al data beschikbaar is en hoe dat er uit
ziet.

Gertjan

On Fri, 2012-12-28 at 15:52 +0100, Floris Looijesteijn wrote:
> Hallo!
> 
> 
> Heeft iemand al eens gekeken of wij deze informatie ook kunnen
> gebruiken?
> 
> 
> 
> http://www.nu.nl/gadgets/2992181/wegaanpassingen-sneller-navigatiesystemen.html
> 
> 
> 
> Groet,
> Floris
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] websites bij POI

[Gertjan Idema]

On Fri, 2012-10-26 at 13:56 +0200, Floris Looijesteijn wrote:
> Hallo!
> 
> 
> 
> Ik tag zelf zoveel mogelijk de website bij POI als die bekend is.
> 
> Meestal kun je op de website namelijk extra info zoals openingstijden,
> menu of catalogus vinden.
> 
> 
> Persoonlijk tag ik website alleen als er echt een specifieke
> site/pagina voor die vestiging is.
> Ik ga dus niet op elk treinstation als website www.ns.nl zetten.
> 
> 
> In keepright (http://keepright.ipax.at) komen er redelijk wat fouten
> voorbij voor de website tag, dus ik ben benieuwd wat jullie nuttige
> websites vinden.
> 
> 
> Een paar voorbeelden:
> 
> 
> Stadhuis van Haarlem: www.haarlem.nl
> http://www.openstreetmap.org/browse/way/91770410
> 
> 
> V&D in Haarlem: www.vd.nl
> http://www.openstreetmap.org/browse/way/100611687

Mede gezien je eerder opmerking zou ik de url veranderen in
http://www.vd.nl/vestiging/haarlem_centrum

> 
> 
> Voorbeeldje van restaurant met een eigen (slechte :) website:
> http://www.openstreetmap.org/browse/node/1326350383
> 
> 
> Vooral van de eerste twee vraag ik me af of die nuttig zijn.
> 
> 
> Groet,
> Floris
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] BAG data en de Import Guidelines

[Gertjan Idema]

On Sun, 2012-10-21 at 17:33 +0200, Cartinus wrote:

> On 10/21/2012 04:04 PM, Sebastiaan Couwenberg wrote:
> > Nu de discussies over het importeren van BAG data goed op gang komen heb
> > ik eens gekeken hoe hiervoor rekening te houden met de Import Guidelines
> 
> 
> 
> 
> > We hebben nu toegang tot de meest authoratieve bron voor deze grenzen,
> > waardoor ik geen bezwaar verwacht tegen het gebruik hiervan. Maar
> > natuurlijk onder voorwaarde dat dit zorgvuldig gebeurt. Het is erg
> > makkelijk om aangrenzende boundaries incompleet te maken bij het
> > splitsen van gemeente grenzen ten behoeve van de woonplaats grenzen daarin.
> 
> De gebouwen kunnen goed in kleine hapjes worden geïmporteerd. Voor de
> woonplaatsgrenzen is dat denk ik echter vragen om problemen, die zijn
> veel te veel verweven met elkaar.
> > Voor het opnemen van de grenzen moeten we denk ik ook een "officiele"
> > procedure ontwikkelen al dan niet geautomatiseerd. Ik meen dat de Deense
> > community een bot heeft draaien die de grenzen daar automatisch
> > corrigeert met de meest recente overheids data, zoiets wil ik voor
> > Nederland ook. Maar tools die het makkelijk maken om de grenzen in OSM
> > op te nemen zonder andere boundaries te slopen vind ik ook wel een goed
> > idee. Ik denk dat de woonplaats export de ways vast moet splitsen op de
> > punten waar grenzen bij elkaar komen om het eenvoudiger in OSM op te
> > nemen. Dit kan in de osmosis plugin, of ik kan daar een script voor
> > schrijven om mee te beginnen.
> 
> Waarom het wiel opnieuw uitvinden? ogr2osm is voor zover ik weet
> speciaal ontwikkeld voor het importeren (als multipolygonen) van
> aansluitende vlakken.

Helaas sluiten de vlakken van de woonplaats multipolygonen in de BAG
vaak niet op elkaar aan. Ik betwijfel of ogr2osm daarmee om kan gaan,
maar ga het zeker proberen.

Gertjan

> 
> - - - - - - - -
> 
> De rest van het verhaal klinkt goed.
> 
> 


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Het taggen van BAG data.

[Gertjan Idema]

On Sun, 2012-10-21 at 14:42 +0200, Just van den Broecke wrote:

> On 20-10-12 22:58, Stefan de Konink wrote:
> > On Sat, 20 Oct 2012, Gertjan Idema wrote:
> >
> >> Heb je een voorbeeld van een mutatie bestand? Ik heb er nog nooit een
> >> gezien.
> >
> > Volgens mij staat die op nlextract.nl
> Klopt:
> https://github.com/opengeogroep/NLExtract/tree/master/bag/test/mutatie

En aangezien ik een Git clone heb dus ook gewoon op mijn eigen pc'tje ;-).

Bedankt beiden voor de tip.

Groeten, Gertjan

> Just
> >
> > Stefan
> >
> >
> > ___
> > Talk-nl mailing list
> > Talk-nl@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-nl
> >
> >
> > !DSPAM:1,5082f4f0256191152810491!
> >
> >
> >
> > ___
> > Talk-nl mailing list
> > Talk-nl@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-nl
> >
> 
> 
> 
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Het taggen van BAG data.

[Gertjan Idema]

On Sun, 2012-10-21 at 11:52 +0200, Frank Steggink wrote:

> Als een bouwvergunning verleend is, hoeft nog niet te betekenen dat al 
> met de bouw gestart is. Ik wist trouwens niet dat deze status ook in de 
> BAG aanwezig kan zijn. Geldt dit ook voor sloopvergunningen?

Het klopt dat de bouw meestal niet start zodra de bouwvergunning is
verleend. Mijn overweging om zo'n gebouw toch aan aan een .osm file toe
te voegen is de volgende:
In de praktijk zal er tijd zitten tussen het moment van genereren van
een .osm file en het moment dat een mapper er mee aan de gang gaat. Door
het pand als "building=construction" toe te voegen, weet de mapper dat
er op die plek iets gaat gebeuren en kan hij bijvoorbeeld in de BAG web
kijken wat de huidige status van het pand is.
Iets als "building=planned" is volgens mij niet gedocumenteerd in OSM en
zal door Mapnik cs als bestaand pand gerenderd worden.


Sloop vergunningen staan ook in de BAG. Hier is het complete lijstje:

Bouwvergunning verleend
Niet gerealiseerd pand
Bouw gestart
Pand in gebruik (niet ingemeten)
Pand in gebruik
Sloopvergunning verleend
Pand gesloopt
Pand buiten gebruik

Groeten, Gertjan

> Groeten,
> 
> Frank
> 
> On 21-10-2012 11:36, Hugo Hölscher wrote:
> >
> > Lijkt me de goede benadering. Hugo
> >
> > Op 21 okt. 2012 11:07 schreef "Gertjan Idema"  > <mailto:g.id...@zonnet.nl>> het volgende:
> >
> > On Sun, 2012-10-21 at 10:49 +0200, Hugo Holscher wrote:
> >> Het viel mij op dat de gegevens van het BAG (tenminste zo als ik
> >> ze in de BAG viewer zie), data bevat die nog niet bestaan. Als je
> >> deze id zoekt: 039710014064, vind je een huis en adres in
> >> Heemstede waarvan de bouw nog niet eens begonnen is. Verder weet
> >> ik dat de bouw vergunning aan verandering onderhevig is. Gaan we
> >> met bulk up-loads nu de mogelijk toekomstige kaart van Nederland
> >> maken of is het wijsheid om de locaties waarvan de status is:
> >> “bouwvergunning verleend” er nog uit laten? 
> >> Hugo 
> >
> > Mijn insteek op dit moment is om gebouwen met status "Bouw
> > gestart" te taggen als building=construction. Voor "Bouwvergunning
> > verleend" kan je overwegen om dat ook te doen, om wat meer
> > informatie te geven aan een mapper die ziet dat er wat gaande is
> > op een stukje grond. Daarnaast voeg ik een tag "bag:status" toe.
> >
> > Gertjan
> >> *From:*Gertjan Idema <mailto:g.id...@zonnet.nl> 
> >> *Sent:*Saturday, October 20, 2012 8:54 PM 
> >> *To:*talk-nl@openstreetmap.org <mailto:talk-nl@openstreetmap.org> 
> >> *Subject:*Re: [OSM-talk-nl] Het taggen van BAG data. 
> >> On Sat, 2012-10-20 at 13:21 +0200, Just van den Broecke wrote:
> >>> Beste Gertjan e.a,
> >>>
> >>> Een goed plan, ik wil wel meedenken. btw: De BAG is net deze week
> >>> ververst met versie 8 sept en 8 okt:
> >> Fijn dat je meedenkt :-)
> >>> 
> >>> http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml
> >>>   
> >>> (Atom).
> >>> e.e.a. moet ook simpeler worden in de toekomst:
> >>> http://drupal.pdokloket.nl/nl/producten/pdok-downloads/atomfeeds
> >>>
> >>> Ik probeer wat aan te vullen onder...het blijft een taai onderwerp.
> >>>
> >>>
> >>> On 17-10-12 13:11, Gertjan Idema wrote:
> >>> > Er is een aantal initiatieven gaande voor het opnemen van BAG data 
> >>> in
> >>> > Openstreetmap.
> >>> > - ruudblank heeft veel werk verricht in Gorinchem.
> >>> > - rullzer in de omgeving Purmerend
> >>> > - mijn eigen initiatief op basis waarvan Minko (Amersfoort), PeeWee
> >>> > (Leusden) en Sebastiaan (Oldambt) nu  kleinschalig
> >>> >aan het testen zijn.
> >>> > - en ongetwijfeld nog meer.
> >>> >
> >>> > Helaas is er nog geen standaard voor het taggen van BAG data. Mijn 
> >>> idee
> >>> > van deze discussie is om hier samen te vatten wat er tot nu toe 
> >>> gedaan
> >>> > en besproken is over het taggen van data afkomstig uit de BAG.
> >>> > Vervolgens hoop ik dat we het samen eens kunnen worden over een
> >>> > standaard. Deze kan dan opgenomen worden op de Wiki pagina en
> >>> > geïntegreerd in tools en scripts. He

Re: [OSM-talk-nl] Het taggen van BAG data.

[Gertjan Idema]

On Sun, 2012-10-21 at 10:49 +0200, Hugo Holscher wrote:
> Het viel mij op dat de gegevens van het BAG (tenminste zo als ik ze in
> de BAG viewer zie), data bevat die nog niet bestaan. Als je deze id
> zoekt: 039710014064, vind je een huis en adres  in Heemstede
> waarvan de bouw nog niet eens begonnen is. Verder weet ik dat de bouw
> vergunning aan verandering onderhevig is. Gaan we met bulk up-loads nu
> de mogelijk toekomstige kaart van Nederland maken of is het wijsheid
> om de locaties waarvan de status is: “bouwvergunning verleend” er nog
> uit laten?
>  
> Hugo

Mijn insteek op dit moment is om gebouwen met status  "Bouw gestart" te
taggen als building=construction. Voor "Bouwvergunning verleend" kan je
overwegen om dat ook te doen, om wat meer informatie te geven aan een
mapper die ziet dat er wat gaande is op een stukje grond. Daarnaast voeg
ik een tag "bag:status" toe.

Gertjan
>  
> From: Gertjan Idema 
> Sent: Saturday, October 20, 2012 8:54 PM
> To: talk-nl@openstreetmap.org 
> Subject: Re: [OSM-talk-nl] Het taggen van BAG data.
>  
> 
> On Sat, 2012-10-20 at 13:21 +0200, Just van den Broecke wrote: 
> 
> > Beste Gertjan e.a,
> > 
> > Een goed plan, ik wil wel meedenken. btw: De BAG is net deze week 
> > ververst met versie 8 sept en 8 okt:
> 
> Fijn dat je meedenkt :-) 
> 
> > http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml
> >  
> > (Atom).
> > e.e.a. moet ook simpeler worden in de toekomst:
> > http://drupal.pdokloket.nl/nl/producten/pdok-downloads/atomfeeds
> > 
> > Ik probeer wat aan te vullen onder...het blijft een taai onderwerp.
> > 
> > 
> > On 17-10-12 13:11, Gertjan Idema wrote:
> > > Er is een aantal initiatieven gaande voor het opnemen van BAG data in
> > > Openstreetmap.
> > > - ruudblank heeft veel werk verricht in Gorinchem.
> > > - rullzer in de omgeving Purmerend
> > > - mijn eigen initiatief op basis waarvan Minko (Amersfoort), PeeWee
> > > (Leusden) en Sebastiaan (Oldambt) nu  kleinschalig
> > >aan het testen zijn.
> > > - en ongetwijfeld nog meer.
> > >
> > > Helaas is er nog geen standaard voor het taggen van BAG data. Mijn idee
> > > van deze discussie is om hier samen te vatten wat er tot nu toe gedaan
> > > en besproken is over het taggen van data afkomstig uit de BAG.
> > > Vervolgens hoop ik dat we het samen eens kunnen worden over een
> > > standaard. Deze kan dan opgenomen worden op de Wiki pagina en
> > > geïntegreerd in tools en scripts. Het doel hierbij is niet om zoveel
> > > mogelijk BAG dat in openstreetmap te krijgen, maar om te zorgen dat dit
> > > consistent gebeurt.
> > >
> > > Eerst maar eens een inventarisatie:
> > >
> > > Adres tags op pand of losse nodes
> > > =
> > > De BAG maakt onderscheid tussen panden, verblijfsobjecten en
> > > nummeraanduidingen. Een pand kan meerdere verblijfsobjecten bevatten.
> > Ja het meestvoorkomende, maar ook omgekeerd (meerdere Panden bij VBO), 
> > maar moet daarvan nog voorbeeld zien.
> 
> Hier is een mooi voorbeeld: VBO 034401091735 (Ambachtsweg 52,
> Utrecht) ik heb ook nog even geen
> idee hoe we dit het beste in OSM zouden kunnen mappen.
> Een ander voorbeeld is VBO 034410054743 (Hoogravenseweg 140A).
> Hier zijn 2 panden samengevoegd en vervolgens opgedeeld in 7
> verblijfsobjecten.
> Ik kom 161 VBO's met meerdere panden tegen in Utrecht stad, de meesten
> met 2 panden per VBO. 
> 
> > > Tot nu toe heb ik de adressen als volgt getagd:
> > > Voor panden met een enkel verblijfsobject heb ik de adres tags
> > > (addr:housenumber, addr:postcode, addr:street) aan het pand gekoppeld
> > > met in tag "ref:bagid" het BAG id van het pand.
> > > Voor panden met meerdere verblijfsobjecten heb ik aan het pand geen
> > > adres tags gekoppeld, dit kunnen immers verschillende straten zijn. De
> > > adres tags heb ik aan losse nodes gekoppeld met in tag "ref:bagid" het
> > > BAG id van de nummeraanduiding.
> > >
> > > ruudblank heeft er in Gorinchem voor gekozen om alle adressen los te
> > > koppelen van het pand. Als BAG referentie gebruikt hij het BAG id van
> > > het verblijfsobject in de tag "bag:vbo_id" en op de panden het BAG id
> > > van het pand in "bag:pand_id".
> > >
> > > rullzer maakt hetzelfde onderscheid als ik tussen panden met 1 of met
> > > meer verblijfsobjecten, maar gebruikt geen BAG id op de adres nodes.
> &

Re: [OSM-talk-nl] Het taggen van BAG data.

[Gertjan Idema]

On Sat, 2012-10-20 at 13:24 +0200, Just van den Broecke wrote:

> On 20-10-12 10:05, Gertjan Idema wrote:
> > On Sat, 2012-10-20 at 00:53 +0200, Stefan de Konink wrote:
> >> On Wed, 17 Oct 2012, Floris Looijesteijn wrote:
> >>
> >> > Is het misschien een idee om hier een keer een avond/middag voor bij 
> >> > elkaar
> >> > te komen?Dat gaat alleen werken als de hoofdrolspelers allemaal aanwezig
> >> > kunnen zijn natuurlijk.
> >>
> >> In de vorige discussie met onderandere Ldp kwam ook naar voren: hoe gaan
> >> we dit updaten. Iedere maand komt er een nieuwe BAG uit, en een import is
> >> eenmalig. Dus je wilt een delta kunnen trekken op basis van een BAGid.
> > Mijn idee is om bij uitkomst van een nieuwe BAG extract een delta te
> > trekken tussen deze nieuwe BAG extract en een Planet dump van OSM.
> Er bestaan voor de BAG ook delta's, zelfs dagelijks meen ik, 
> Mutatie-leveringen. Is wel betaald abbo...maar als 1 iemand de abbo 
> heeft mag je m.i. gratis doorleveren.

Een dagelijks mutatiebestand lijkt mij niet praktisch werkbaar. Ik denk
eerder aan 1x per maand of 1x per kwartaal. Tenzij er uiteindelijk
besloten wordt om alles te automatiseren.
Heb je een voorbeeld van een mutatie bestand? Ik heb er nog nooit een
gezien.

Groeten, Gertjan

> >
> > De BAG velden waarop ik wil vergelijken zijn identificatie,
> > aanduidingrecordcorrectie, en begindatumtijdvakgeldigheid.
> > Onder het kopje 'Versiebeheer' in het eerste mailtje van deze thread heb
> > ik hier al wat meer over geschreven.
> > Ik ben van plan om hier mee te gaan testen zodra ik over een nieuwe BAG
> > extract beschik, maar heb sinds 8-8-2012 nog geen nieuwe langs zien komen.
> >
> > Groeten, Gertjan
> >> Stefan
> >> ___ Talk-nl mailing 
> >> listtalk...@openstreetmap.org  <mailto:Talk-nl@openstreetmap.org>  
> >> http://lists.openstreetmap.org/listinfo/talk-nl  
> >> !DSPAM:1,507ea4b8320128641516732!
> >> ___ Talk-nl mailing 
> >> listtalk...@openstreetmap.org  <mailto:Talk-nl@openstreetmap.org>  
> >> http://lists.openstreetmap.org/listinfo/talk-nl
> >
> >
> >
> > ___
> > Talk-nl mailing list
> > Talk-nl@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-nl
> >
> 
> 


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Het taggen van BAG data.

[Gertjan Idema]

On Sat, 2012-10-20 at 13:21 +0200, Just van den Broecke wrote:

> Beste Gertjan e.a,
> 
> Een goed plan, ik wil wel meedenken. btw: De BAG is net deze week 
> ververst met versie 8 sept en 8 okt:

Fijn dat je meedenkt :-)

> http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml
>  
> (Atom).
> e.e.a. moet ook simpeler worden in de toekomst:
> http://drupal.pdokloket.nl/nl/producten/pdok-downloads/atomfeeds
> 
> Ik probeer wat aan te vullen onder...het blijft een taai onderwerp.
> 
> 
> On 17-10-12 13:11, Gertjan Idema wrote:
> > Er is een aantal initiatieven gaande voor het opnemen van BAG data in
> > Openstreetmap.
> > - ruudblank heeft veel werk verricht in Gorinchem.
> > - rullzer in de omgeving Purmerend
> > - mijn eigen initiatief op basis waarvan Minko (Amersfoort), PeeWee
> > (Leusden) en Sebastiaan (Oldambt) nu  kleinschalig
> >aan het testen zijn.
> > - en ongetwijfeld nog meer.
> >
> > Helaas is er nog geen standaard voor het taggen van BAG data. Mijn idee
> > van deze discussie is om hier samen te vatten wat er tot nu toe gedaan
> > en besproken is over het taggen van data afkomstig uit de BAG.
> > Vervolgens hoop ik dat we het samen eens kunnen worden over een
> > standaard. Deze kan dan opgenomen worden op de Wiki pagina en
> > geïntegreerd in tools en scripts. Het doel hierbij is niet om zoveel
> > mogelijk BAG dat in openstreetmap te krijgen, maar om te zorgen dat dit
> > consistent gebeurt.
> >
> > Eerst maar eens een inventarisatie:
> >
> > Adres tags op pand of losse nodes
> > =
> > De BAG maakt onderscheid tussen panden, verblijfsobjecten en
> > nummeraanduidingen. Een pand kan meerdere verblijfsobjecten bevatten.
> Ja het meestvoorkomende, maar ook omgekeerd (meerdere Panden bij VBO), 
> maar moet daarvan nog voorbeeld zien.

Hier is een mooi voorbeeld: VBO 034401091735 (Ambachtsweg 52,
Utrecht) ik heb ook nog even geen
idee hoe we dit het beste in OSM zouden kunnen mappen.
Een ander voorbeeld is VBO 034410054743 (Hoogravenseweg 140A). Hier
zijn 2 panden samengevoegd en vervolgens opgedeeld in 7
verblijfsobjecten.
Ik kom 161 VBO's met meerdere panden tegen in Utrecht stad, de meesten
met 2 panden per VBO. 

> > Tot nu toe heb ik de adressen als volgt getagd:
> > Voor panden met een enkel verblijfsobject heb ik de adres tags
> > (addr:housenumber, addr:postcode, addr:street) aan het pand gekoppeld
> > met in tag "ref:bagid" het BAG id van het pand.
> > Voor panden met meerdere verblijfsobjecten heb ik aan het pand geen
> > adres tags gekoppeld, dit kunnen immers verschillende straten zijn. De
> > adres tags heb ik aan losse nodes gekoppeld met in tag "ref:bagid" het
> > BAG id van de nummeraanduiding.
> >
> > ruudblank heeft er in Gorinchem voor gekozen om alle adressen los te
> > koppelen van het pand. Als BAG referentie gebruikt hij het BAG id van
> > het verblijfsobject in de tag "bag:vbo_id" en op de panden het BAG id
> > van het pand in "bag:pand_id".
> >
> > rullzer maakt hetzelfde onderscheid als ik tussen panden met 1 of met
> > meer verblijfsobjecten, maar gebruikt geen BAG id op de adres nodes.
> Een lastige, ik zou in ieder geval zo dicht mogelijk bij het BAG model 
> blijven...Bijv. kunnen VBOs en (LIG/STA) niet gewoon zelf OSM punt-nodes 
> zijn (plm 9 miljoen in NL!)? En gekoppeld via relaties aan Panden ? In 
> het achterhoofd ook het soort gebruik van OSM adressen: Geocoders, 
> Door-to-door navigation. En verder aansluiten bij algemene 
> OSM-conventies voor adressen.

Relaties tussen panden en verblijfsobjecten/adressen worden voor zover
ik weet niet gebruikt in OSM. En gezien het feit dat associatedStreet
relaties amper gebruikt worden vanwege de complexiteit, denk ik dat een
eventuele associatedBuilding relatie het niet gaat redden.
Voor de meeste toepassingen zal een relatie tussen pand en adres niet
echt belangrijk zijn, hoewel Cartinus aangaf dat de relatie tussen
hoofdadres en nevenadressen (leveranciersadressen) in de transportsector
wel gebruikt wordt.


> >
> > AssociatedStreet relaties
> > =
> > AssociatedStreet relaties bieden veel voor en nadelen en het laatste
> > woord is er nog niet over gesproken. Een voordeel dat in mijn ogen
> > onderbelicht is, is het bij elkaar voegen van losse stukjes van dezelfde
> > straat. Hierdoor kunnen gemakkelijke relaties gelegd worden tussen
> > straten in OSM en straten uit andere bronnen. Dat gaat echter alleen
> > werken associatedStreets gemeengoed zijn. Gezien de complexiteit bij het
> > in

Re: [OSM-talk-nl] Het taggen van BAG data.

[Gertjan Idema]

Beste Pander,

Als je mij een lijstje met correcties stuurt, wil ik wel kijken of ik er
BAG id's aan kan koppelen. 

Gertjan

On Sat, 2012-10-20 at 13:54 +0200, Pander wrote:

> On 2012-10-20 13:38, Just van den Broecke wrote:
> > Beste Pander,
> > 
> > Heb je de standaard terugmelding per email al geprobeerd:
> > b...@kadaster.nl
> > zie
> > http://bag.vrom.nl/de_bag_gebruiken/terugmelden
> > 
> > "Als u gerede twijfel heeft over de juistheid van de informatie in de
> > BAG, dan kunt u dit per e-mail melden op b...@kadaster.nl. In het
> > onderwerpveld van de e-mail dient u de gemeente te vermelden waarbinnen
> > het object valt. De betreffende object ID('s) dient u te vermelden in uw
> > bericht, plus hetgeen u over twijfelt. Voor private afnemers geldt geen
> > terugmeldingsplicht. Bij gerede twijfel kan er rechtstreeks bij de
> > bronhouder teruggemeld worden."
> 
> Dank je wel. Alleen heb ik niet een overzicht van die ID's. Doe moeten
> er bijgezocht worden als mijn correcties worden uitgevoerd. Aangezien ik
> correcties doe nadat het ID gestript is is dat een hoop extra werk.
> 
> Is er iemand die veel met BAG-gegevens werkt en al bestaande scripts
> heeft die mijn lijst van correcties als een filter op wil nemen en zo
> rapportjes kan genereren om terug te zenden naar het Kadaster.
> 
> Voordeel als je hiermee aan de slag gaat is dat de gecorrigeerde
> BAG-gegevens van veel hogere kwaliteit zijn. Vanuit OpenTaal ga ik door
> de BAG-gegevens voor spellingcontrole maar de geografische informatie
> interesseert ons verder niet. Dit ligt om die reden buiten ons domein.
> Vandaar de zoektocht naar een BAG-liefhebber om het stokje aan door te
> geven.
> 
> > groeten,
> > 
> > Just
> > On 20-10-12 13:32, Pander wrote:
> >> On 2012-10-20 13:21, Just van den Broecke wrote:
> >>> Beste Gertjan e.a,
> >>>
> >>> Een goed plan, ik wil wel meedenken. btw: De BAG is net deze week
> >>> ververst met versie 8 sept en 8 okt:
> >>> http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml
> >>>
> >>> (Atom).
> >>> e.e.a. moet ook simpeler worden in de toekomst:
> >>> http://drupal.pdokloket.nl/nl/producten/pdok-downloads/atomfeeds
> >>>
> >>> Ik probeer wat aan te vullen onder...het blijft een taai onderwerp.
> >>
> >> Voor wie interesse heeft: ik heb nog een hele lijst van correcties op de
> >> BAG-gegevens. Met name coderings- en typefouten zitten er redelijk wat
> >> in.
> >>
> >> Ook zou het handig zijn als het Kadaster er iets mee zou willen doen?
> >>
> >> Ik heb ze al eens geschreven over fouten in toponiemen uit 1:25.000
> >> kaarten (TOP25) maar toen hadden ze geen interesse. Hun reden was dat ze
> >> er zelf al mee aan de slag waren.
> >>
> >> Voor BAG denk ik niet dat ze op de hoogte zijn van deze fouten, ook
> >> omdat het een gigantische collectie is. Heeft iemand een ingang
> >> hiervoor? Volgens de wet moeten ze volgens mij openstaan voor
> >> terugmelding van correcties.
> >>
> >>> On 17-10-12 13:11, Gertjan Idema wrote:
> >>>> Er is een aantal initiatieven gaande voor het opnemen van BAG data in
> >>>> Openstreetmap.
> >>>> - ruudblank heeft veel werk verricht in Gorinchem.
> >>>> - rullzer in de omgeving Purmerend
> >>>> - mijn eigen initiatief op basis waarvan Minko (Amersfoort), PeeWee
> >>>> (Leusden) en Sebastiaan (Oldambt) nu  kleinschalig
> >>>> aan het testen zijn.
> >>>> - en ongetwijfeld nog meer.
> >>>>
> >>>> Helaas is er nog geen standaard voor het taggen van BAG data. Mijn idee
> >>>> van deze discussie is om hier samen te vatten wat er tot nu toe gedaan
> >>>> en besproken is over het taggen van data afkomstig uit de BAG.
> >>>> Vervolgens hoop ik dat we het samen eens kunnen worden over een
> >>>> standaard. Deze kan dan opgenomen worden op de Wiki pagina en
> >>>> geïntegreerd in tools en scripts. Het doel hierbij is niet om zoveel
> >>>> mogelijk BAG dat in openstreetmap te krijgen, maar om te zorgen dat dit
> >>>> consistent gebeurt.
> >>>>
> >>>> Eerst maar eens een inventarisatie:
> >>>>
> >>>> Adres tags op pand of losse nodes
> >>>> =
> >>>> De BAG maakt onderscheid tussen panden, verblijfsobjecten en
> >&

Re: [OSM-talk-nl] Het taggen van BAG data.

[Gertjan Idema]

On Sat, 2012-10-20 at 00:53 +0200, Stefan de Konink wrote:

> On Wed, 17 Oct 2012, Floris Looijesteijn wrote:
> 
> > Is het misschien een idee om hier een keer een avond/middag voor bij elkaar
> > te komen?Dat gaat alleen werken als de hoofdrolspelers allemaal aanwezig
> > kunnen zijn natuurlijk.
> 
> In de vorige discussie met onderandere Ldp kwam ook naar voren: hoe gaan 
> we dit updaten. Iedere maand komt er een nieuwe BAG uit, en een import is 
> eenmalig. Dus je wilt een delta kunnen trekken op basis van een BAGid.

Mijn idee is om bij uitkomst van een nieuwe BAG extract een delta te
trekken tussen deze nieuwe BAG extract en een Planet dump van OSM.

De BAG velden waarop ik wil vergelijken zijn identificatie,
aanduidingrecordcorrectie, en begindatumtijdvakgeldigheid. 
Onder het kopje 'Versiebeheer' in het eerste mailtje van deze thread heb
ik hier al wat meer over geschreven.
Ik ben van plan om hier mee te gaan testen zodra ik over een nieuwe BAG
extract beschik, maar heb sinds 8-8-2012 nog geen nieuwe langs zien
komen. 

Groeten, Gertjan

> Stefan
> ___ Talk-nl mailing list 
> Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl 
> !DSPAM:1,507ea4b8320128641516732!
> ___ Talk-nl mailing list 
> Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Het taggen van BAG data.

[Gertjan Idema]

On Wed, 2012-10-17 at 14:29 +0200, Floris Looijesteijn wrote:

> Is het misschien een idee om hier een keer een avond/middag voor bij
> elkaar te komen?
> 
> Dat gaat alleen werken als de hoofdrolspelers allemaal aanwezig kunnen
> zijn natuurlijk.

Lijkt me een goed idee. De vraag is dan natuurlijk even wie de
hoofdrolspelers zijn.
Eerst maar een een paar dagen wachten om  te kijken wie er graag meedoen
in de discussie.

Groeten, Gertjan
> 
> 
> Groet,
> Floris
> 
> 
> 2012/10/17 Floris Looijesteijn 
> 
> Ik zit ook te wachten op duidelijke regels voordat ik Haarlem
> ga importeren, goed initiatief.
> 
> 
> 
> Klein opmerking over de huisnummer toevoegingen.
> Waarschijnlijk kan de toevoeging ook wel eens een nummer zijn.
> Het zal niet de eerste keer zijn dat een pakketje bestemd voor
> 11 2 (of 11-2) naar huisnummer 112 wordt gestuurd.
> Dus minstens een spatie wat mij betreft. Of controleren of het
> alleen letter is en de spatie weglaten.
> 
> 
> Ik ben benieuwd hoe de data voor mijn pand is, op mijn gevel
> hangt een bordje met A terwijl men in Haarlem met 'Zwart' en
> 'Rood' werkt.
> 
> 
> Groet,
> Floris
> 
> 
> 2012/10/17 Gertjan Idema 
> 
> Er is een aantal initiatieven gaande voor het opnemen
> van BAG data in Openstreetmap.
> - ruudblank heeft veel werk verricht in Gorinchem.
> - rullzer in de omgeving Purmerend
> - mijn eigen initiatief op basis waarvan Minko
> (Amersfoort), PeeWee (Leusden) en Sebastiaan (Oldambt)
> nu  kleinschalig
>   aan het testen zijn.
> - en ongetwijfeld nog meer.
> 
> Helaas is er nog geen standaard voor het taggen van
> BAG data. Mijn idee van deze discussie is om hier
> samen te vatten wat er tot nu toe gedaan en besproken
> is over het taggen van data afkomstig uit de BAG.
> Vervolgens hoop ik dat we het samen eens kunnen worden
> over een standaard. Deze kan dan opgenomen worden op
> de Wiki pagina en geïntegreerd in tools en scripts.
> Het doel hierbij is niet om zoveel mogelijk BAG dat in
> openstreetmap te krijgen, maar om te zorgen dat dit
> consistent gebeurt.
> 
> Eerst maar eens een inventarisatie:
> 
> Adres tags op pand of losse nodes
> =
> De BAG maakt onderscheid tussen panden,
> verblijfsobjecten en nummeraanduidingen. Een pand kan
> meerdere verblijfsobjecten bevatten.
> Tot nu toe heb ik de adressen als volgt getagd:
> Voor panden met een enkel verblijfsobject heb ik de
> adres tags (addr:housenumber, addr:postcode,
> addr:street) aan het pand gekoppeld met in tag
> "ref:bagid" het BAG id van het pand.
> Voor panden met meerdere verblijfsobjecten heb ik aan
> het pand geen adres tags gekoppeld, dit kunnen immers
> verschillende straten zijn. De adres tags heb ik aan
> losse nodes gekoppeld met in tag "ref:bagid" het BAG
> id van de nummeraanduiding.
> 
> ruudblank heeft er in Gorinchem voor gekozen om alle
> adressen los te koppelen van het pand. Als BAG
> referentie gebruikt hij het BAG id van het
> verblijfsobject in de tag "bag:vbo_id" en op de panden
> het BAG id van het pand in "bag:pand_id".
> 
> rullzer maakt hetzelfde onderscheid als ik tussen
> panden met 1 of met meer verblijfsobjecten, maar
> gebruikt geen BAG id op de adres nodes.
> 
> AssociatedStreet relaties
> =
> AssociatedStreet relaties bieden veel voor en nadelen
> en het laatste woord is er nog niet over gesproken.
> Een voordeel dat in mijn ogen onderbelicht is, is het
> bij elkaar voegen van losse stukjes van dezelfde
> straat. Hierdoor kunnen gemakkelijke relaties gelegd
> worden tussen straten in OS

Re: [OSM-talk-nl] Het taggen van BAG data.

[Gertjan Idema]

Nog een toevoeging naar aanleiding van Cartinus:
Het veld huisletter in mijn BAG database (8-8-2012) bevat alleen maar
hoofd- en kleine letters, dus geen cijfers.

Gertjan
On Thu, 2012-10-18 at 17:39 +0200, Gertjan Idema wrote:

> On Wed, 2012-10-17 at 20:06 +0200, Cartinus wrote: 
> 
> > On 10/17/2012 01:11 PM, Gertjan Idema wrote:
> > > Adres tags op pand of losse nodes
> > > =
> > > De BAG maakt onderscheid tussen panden, verblijfsobjecten en
> > > nummeraanduidingen. Een pand kan meerdere verblijfsobjecten bevatten.
> > > Tot nu toe heb ik de adressen als volgt getagd:
> > >  Voor panden met een enkel verblijfsobject heb ik de adres tags
> > > (addr:housenumber, addr:postcode, addr:street) aan het pand gekoppeld
> > > met in tag "ref:bagid" het BAG id van het pand.
> > >  Voor panden met meerdere verblijfsobjecten heb ik aan het pand geen
> > > adres tags gekoppeld, dit kunnen immers verschillende straten zijn. De
> > > adres tags heb ik aan losse nodes gekoppeld met in tag "ref:bagid" het
> > > BAG id van de nummeraanduiding.
> > > 
> > > ruudblank heeft er in Gorinchem voor gekozen om alle adressen los te
> > > koppelen van het pand. Als BAG referentie gebruikt hij het BAG id van
> > > het verblijfsobject in de tag "bag:vbo_id" en op de panden het BAG id
> > > van het pand in "bag:pand_id".
> > > 
> > > rullzer maakt hetzelfde onderscheid als ik tussen panden met 1 of met
> > > meer verblijfsobjecten, maar gebruikt geen BAG id op de adres nodes.
> > 
> > Hoe nuttig is het BAG id van de nummeraanduiding voor adres nodes (voor
> > OSM)? In principe zou in Nederland de combinatie postcode en huisnummer
> > uniek moeten zijn, dus daarmee zou je dan terug kunnen koppelen aan die
> > BAG tabel.
> > 
> > Als je het BAG id van het verblijfsobject gebruikt, dan kun je in OSM
> > zelf zien dat bijv. de verschillende adressen van de voordeur en de
> > achterdeur bij hetzelfde verblijfsobject horen. (Ik werk voor een
> > transportonderneming en dat vinden wij interessante informatie.) Zeker
> > als je op één of andere manier in de tag of de waarde duidelijk maakt
> > dat het om een verblijfsobject id gaat. (Ik weet dat ze allemaal uit één
> > reeks komen, maar dan moet ik weer in de BAG zelf kijken en niet in OSM.)
> 
> Het Bag id van het verblijfsobject is inderdaad misschien logischer. Op
> een pand met een enkel verblijfsobject zouden deze misschien ook kunnen 
> zetten:
> 
> bag:vbo_id en bag:pnd_id (of bag:pand_id zoals in Gorinchem) 
> 
> > > AssociatedStreet relaties
> > > =
> > 
> > Gewoon weglaten. Ik heb ze zelf in het verleden ook aangemaakt, maar het
> > is te foutgevoelig en te lastig bij te houden bij handmatig mappen.
> > 
> > > addr:city en addr:country tags
> > > =
> > > Toevoegen van addr:city en addr:country tags aan adressen gaat bij het
> > > importeren van BAG data in een moeite mee. De vraag is of het wenselijk
> > > is om dat ook te doen. Het zorgt voor erg veel redundantie.
> > > ruudblank voegt addr:city toe, rullzer niet.
> > > Zelf heb ik het tot nu toe niet gedaan, maar ik neig er steeds meer naar
> > > om addr:city toch maar te gaan toevoegen.
> > 
> > In Denemarken hebben ze ooit alle adressen geïmporteerd. Daar hadden ze
> > wel addr:city toegevoegd, omdat ze (toen) niet zo'n complete set grenzen
> > hadden als nu in Nederland. De tag addr:country hadden ze weggelaten.
> > Later kwam er iemand van buiten Denemarken en die voegde dat alsnog toe.
> > Gevolg: stel boze Denen. Geen idee of het is teruggedraaid of niet.
> 
> De woonplaatsgrenzen zijn nog zeker niet compleet in OSM in Nederland,
> maar via de BAG wel beschikbaar. 
> 
> > 
> > Bij met de hand adressen taggen heb ik nergens addr:city toegevoegd. Ik
> > kan namelijk maar twee situaties bedenken waarbij je addr:city m.b.v. de
> > grenzen niet automatisch zou kunnen toevoegen.
> 
> Als je hier bedoeld om ze uiteindelijk wel in OSM te zetten, kunnen we
> het in mijn ogen beter meteen doen.
> Als we het niet doen en besluiten om de link te leggen via de
> woonplaatsgrenzen, is dat natuurlijk wel complexer en bewerkelijker. 
> 
> > 
> > 1) Het postadres ligt niet in dezelfde woonplaats als het pand.
> > 2) Het pand staat op de grens en ligt dus in twee woonplaatsen.
> 
> Als ik het goed begrepen heb kan 1 officieel niet.
> 
> > Ik weet niet of 1) kan in Nederland. 2) zie je bij het met de han

Re: [OSM-talk-nl] Het taggen van BAG data.

[Gertjan Idema]

On Wed, 2012-10-17 at 20:06 +0200, Cartinus wrote:

> On 10/17/2012 01:11 PM, Gertjan Idema wrote:
> > Adres tags op pand of losse nodes
> > =
> > De BAG maakt onderscheid tussen panden, verblijfsobjecten en
> > nummeraanduidingen. Een pand kan meerdere verblijfsobjecten bevatten.
> > Tot nu toe heb ik de adressen als volgt getagd:
> >  Voor panden met een enkel verblijfsobject heb ik de adres tags
> > (addr:housenumber, addr:postcode, addr:street) aan het pand gekoppeld
> > met in tag "ref:bagid" het BAG id van het pand.
> >  Voor panden met meerdere verblijfsobjecten heb ik aan het pand geen
> > adres tags gekoppeld, dit kunnen immers verschillende straten zijn. De
> > adres tags heb ik aan losse nodes gekoppeld met in tag "ref:bagid" het
> > BAG id van de nummeraanduiding.
> > 
> > ruudblank heeft er in Gorinchem voor gekozen om alle adressen los te
> > koppelen van het pand. Als BAG referentie gebruikt hij het BAG id van
> > het verblijfsobject in de tag "bag:vbo_id" en op de panden het BAG id
> > van het pand in "bag:pand_id".
> > 
> > rullzer maakt hetzelfde onderscheid als ik tussen panden met 1 of met
> > meer verblijfsobjecten, maar gebruikt geen BAG id op de adres nodes.
> 
> Hoe nuttig is het BAG id van de nummeraanduiding voor adres nodes (voor
> OSM)? In principe zou in Nederland de combinatie postcode en huisnummer
> uniek moeten zijn, dus daarmee zou je dan terug kunnen koppelen aan die
> BAG tabel.
> 
> Als je het BAG id van het verblijfsobject gebruikt, dan kun je in OSM
> zelf zien dat bijv. de verschillende adressen van de voordeur en de
> achterdeur bij hetzelfde verblijfsobject horen. (Ik werk voor een
> transportonderneming en dat vinden wij interessante informatie.) Zeker
> als je op één of andere manier in de tag of de waarde duidelijk maakt
> dat het om een verblijfsobject id gaat. (Ik weet dat ze allemaal uit één
> reeks komen, maar dan moet ik weer in de BAG zelf kijken en niet in OSM.)

Het Bag id van het verblijfsobject is inderdaad misschien logischer. Op
een pand met een enkel verblijfsobject zouden deze misschien ook kunnen zetten:

bag:vbo_id en bag:pnd_id (of bag:pand_id zoals in Gorinchem)

> > AssociatedStreet relaties
> > =
> 
> Gewoon weglaten. Ik heb ze zelf in het verleden ook aangemaakt, maar het
> is te foutgevoelig en te lastig bij te houden bij handmatig mappen.
> 
> > addr:city en addr:country tags
> > =
> > Toevoegen van addr:city en addr:country tags aan adressen gaat bij het
> > importeren van BAG data in een moeite mee. De vraag is of het wenselijk
> > is om dat ook te doen. Het zorgt voor erg veel redundantie.
> > ruudblank voegt addr:city toe, rullzer niet.
> > Zelf heb ik het tot nu toe niet gedaan, maar ik neig er steeds meer naar
> > om addr:city toch maar te gaan toevoegen.
> 
> In Denemarken hebben ze ooit alle adressen geïmporteerd. Daar hadden ze
> wel addr:city toegevoegd, omdat ze (toen) niet zo'n complete set grenzen
> hadden als nu in Nederland. De tag addr:country hadden ze weggelaten.
> Later kwam er iemand van buiten Denemarken en die voegde dat alsnog toe.
> Gevolg: stel boze Denen. Geen idee of het is teruggedraaid of niet.

De woonplaatsgrenzen zijn nog zeker niet compleet in OSM in Nederland,
maar via de BAG wel beschikbaar.

> 
> Bij met de hand adressen taggen heb ik nergens addr:city toegevoegd. Ik
> kan namelijk maar twee situaties bedenken waarbij je addr:city m.b.v. de
> grenzen niet automatisch zou kunnen toevoegen.

Als je hier bedoeld om ze uiteindelijk wel in OSM te zetten, kunnen we
het in mijn ogen beter meteen doen.
Als we het niet doen en besluiten om de link te leggen via de
woonplaatsgrenzen, is dat natuurlijk wel complexer en bewerkelijker.

> 
> 1) Het postadres ligt niet in dezelfde woonplaats als het pand.
> 2) Het pand staat op de grens en ligt dus in twee woonplaatsen.

Als ik het goed begrepen heb kan 1 officieel niet.

> Ik weet niet of 1) kan in Nederland. 2) zie je bij het met de hand
> taggen, dus dan tag je addr:city alleen in het geval van deze uitzondering.
> 
> Bij een import weet ik niet wat de beste keus is. Testen op conditie 2)
> of gewoon allemaal taggen. Dat laatste kost immers geen moeite.
> 
> > Huisnummers
> > ===
> > De BAG bevat de kolommen huisnummer, huisletter en huisnummertoevoeging.
> > OSM gebruikt alleen de tag "addr:housenumber". Hier is dus een vertaling
> > nodig waarbij je kunt kiezen om wel of geen spaties tussen de
> > verschillende delen van het huisnummer te plaatsen.
> > De BAG laat gemeenten vrij in het gebruik van 

[OSM-talk-nl] Het taggen van BAG data.

[Gertjan Idema]

 in
de BAG data. Helaas krijgt het meest recente record niet de hoogste
waarde voor 'aanduidingrecordcorrectie', maar de waarde 0. Het opslaan
van deze waarde in een OSM tag heeft dus niet zo veel zin. Ik denk dat
je de maximum waarde van 'aanduidingreccordcorrectie' in een OSM tag zou
moeten zetten, maar omdat ik dit proces nog niet helemaal doorgrond, heb
ik dat tot nu toe niet gedaan. Ook zou de betekenis van die tag zonder
grondige documentatie alleen maar voor verwarring zorgen. Daarom heb ik
er voorlopig voor gekozen om een tag "bag:extract" toe te voegen met
daarin de naam van het zip bestand waaruit de BAG data afkomstig is.
Daarmee is in ieder geval de versie van de BAG data af te leiden.
 
Gertjan Idema

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] changeset terugdraaien

[Gertjan Idema]

On Mon, 2012-10-15 at 01:39 +0200, Stefan de Konink wrote:

> On Fri, 12 Oct 2012, Minko wrote:
> 
> > Het uploaden (van behoorlijk veel BAG data) duurt uren en de changeset 
> > wordt niet afgesloten.
> > Soms blijkt die dan toch gewoon afgesloten te zijn op OSM. Ik heb het 
> > uploaden in delen geprobeerd maar ook dat wil niet lukken.
> 
> Als je BAG data toevoegd, behoud je dan een van de vele BAG-object-ids?

Er is nog geen standaard voor het taggen van BAG objecten.

Om het overzichtelijk te houden, start ik een nieuwe thread over dit
onderwerp.

Gertjan


> Stefan
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Fwd: Gebruikersvoorwaarden BAG niet meer van toepassing

[Gertjan Idema]

Bedankt voor de informatie Just.

Zoals ik al in een eerder mailtje schreef, ben in bezig  met BAG
plug-ins voor osmosis. Daarbij maak ik dankbaar gebruik van de nlextract
database. Het voordeel van osmosis plug-ins is dat je output kunt
leveren in alle outputformaten waar osmosis plug-ins voor zijn en ook
gebruik kunt maken van osmosis filters).
De BAG plug ins-bieden zelf  filtering op provincie, gemeente en
woonplaats. Filtering op postcode wil ik ook toevoegen, maar gaat
waarschijnlijk lastig worden voor niet-geadresseerde panden.

Tot nu toe heb ik 3 plug-ins in test fase:

bag-woonplaats-reader: creëert OSM multipolygonen met relevante tags
voor woonplaatsen. (uit woonplaatsactueelbestaand met ontdubbeling)

bag-pand-reader: creëert OSM ways of mulitpolygonen met relevante tags
voor bag panden. Nu nog zonder adresgegevens, maar die volgen
binnenkort.

bag-adres-reader: creëert  OSM nodes met adresgegevens.

Allemaal nog work-in-progress, maar de eerste resultaten zijn
veelbelovend. Als je geïnteresseerd in voorbeeldbestandjes van een
bepaald gebied stuur ik je die graag toe.

Voor zover mij bekend, is er nog geen consensus over het mappen en
taggen van uit BAG afkomstige data in OSM. Daarom hoor ik graag
suggesties hiervoor. Tags die in mijn ogen in ieder geval aanwezig
moeten zijn:
ref:bagid (Bag object Id)
bag:begindatum (begindatumtijdvakgeldigheid)
Met deze twee tags is een terugkoppeling te maken naar de BAG om
mutaties bij te houden en eventueel controlescripts uit te voeren. 

Voor samenwerking met nlextract ben ik zeker in. Bijvoorbeeld door de
plug-ins onder de nlextract paraplu uit te brengen.

Groeten,
Gertjan

On Mon, 2012-09-24 at 12:08 +0200, Just van den Broecke wrote:

> Beste Allemaal,
> 
> Ter info:
> Ik zie veel zaken langskomen en goed beantwoord worden. Ik ben een van 
> de ontwikkelaars van NLExtract (http://nlextract.nl). We hebben als 
> algemeen doel om alle vrije zgn "Basis Registraties" 
> (http://www.e-overheid.nl/onderwerpen/stelselinformatiepunt/basisregistraties)
>  
> zoals BAG en BRT(Top10NL) en later BGT in breedste zin te ontsluiten. In 
> eerste instantie gaat het om conversie van bron (XML/GML) naar PostGIS, 
> maar andere output formats zoals OSM Planet zouden ook interessant 
> kunnen zijn.
> 
> De BAG heeft wat valkuilen waardoor je in de modder kan belanden, een 
> paar zijn genoemd, ik som wat zaken op ter info:
> 
> - de BAG is te downloaden via PDOK Atom feed:
> feed://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml
> - iedere maand (meestal op de 8e) komt een nieuwe versie van de BAG uit
> - algemene documentatie over de BAG: http://www.kadaster.nl/bag
> - BAG gaat alleen over woonplaatsen voor bestuurlijke eenheden
> - voor "hogere" eenheden, i.e. gemeenten, provincies wordt binnen 
> NLExtract verrijking gedaan via (CSV) koppelbestanden
> - sinds kort worden deze koppelbestanden met BAG zelf meegeleverd
> - Stefan is bezig om ook (CBS) wijken en buurten te koppelen
> - bagid's zijn uniek over object typen heen (dus bag:pand_id hoeft m.i. 
> niet, het begrip "bagid" wordt ook binnen basis registraties gebruikt)
> - in de BAG kunnen meerdere versies van een object zitten
> - uit de BAG wordt nooit iets weggegooid
> - bagid's zijn daardoor geen primary keys in XML of tabellen!
> - daarom genereert NLExtract database VIEWs op de tabellen om 
> actueel/bestaande objecten uit te filteren
> - gebruik dus altijd de VIEWs
> - algemene vragen over NLExtract kan ook via onze mailing lijst: 
> https://groups.google.com/forum/?fromgroups#!forum/nlextract
> 
> groeten,
> 
> Just
> 
> On 21-09-12 23:30, Gertjan Idema wrote:
> > On Fri, 2012-09-21 at 21:54 +0200, Pander wrote:
> >> On 2012-09-21 14:23, Gertjan Idema wrote:
> >> > BAG bevat alleen woonplaatsen.
> >> > De nieuwste versie (in ieder geval vanaf 8-8-2012) bevat daarnaast een
> >> > bestand met de relatie tussen woonplaatsen en gemeenten
> >> > (GEM-WPL-RELATIE-08082012.zip)
> >>
> >> Ah. Ja ik zie in de bestanden:
> >>
> >> VBO08082012.zip Verblijfsobject (Woonfunctie/Industriefunctie, ...)
> >> STA08082012.zip Standplaats
> >> OPR08082012.zip Openbare Ruimte (Administratief
> >> gebied/Kunstwerk/Landschappelijk gebied/Spoorbaan/Terrein/Water/Weg)
> >> PND08082012.zip Pand
> >> LIG08082012.zip Ligging
> >> WPL08082012.zip Woonplaats
> >> NUM08082012.zip Nummeraanduiding (Postcode, Huisnummer, ...)
> >> GEM-WPL-RELATIE-08082012.zip Gemeente Woonplaats Relatie
> >>
> > LIG staat voor ligplaats (van woonboten)
> >> > Zelf ben ik bezig met een osmosis plug-in voor BAG (uitgaande van de
> >> >

Re: [OSM-talk-nl] Fwd: Gebruikersvoorwaarden BAG niet meer van toepassing

[Gertjan Idema]

Een nettere manier om de woonplaatsnamen er uit te halen is met xslt.

Ik heb een .xslt bestandje bijgevoegd waarmee je eenvoudig een csv
bestandje kan maken met woonplaats codes en namen.
Instructies voor het gebruik staan in het bestandje.

Gertjan

On Fri, 2012-09-21 at 13:20 +0200, Pander wrote:

> On 2012-09-19 12:14, Minko wrote:
> > En zouden die techneuten dat evt ook op het forum willen delen, of is dat 
> > teveel gevraagd?
> > Zie http://forum.openstreetmap.org/viewtopic.php?pid=274222#p274222
> 
> Op de volgende eenvoudige manier kan ik de woonplaatsen er uit halen:
> 
> cat _*WPL*xml|sed -e 's/>\n 's///'|sed -e
> 's/<\/bag_LVC:woonplaatsNaam>//'|sed -e "s/'/'/g"|sed -e
> 's/â/â/g'|sed -e 's/ë/ë/g'|sed -e 's/û/û/g'|sort|uniq
> 
> Maar hoe is te zien of het om een gemeente, woonplaats of buurtschap gaat?
> 
> Kan ik dan beter met osmosis aan de slag gaan?
> 
> > ZMW schreef:
> >> Is een een techneut die deze BAG data als transparant layer voor JOSM
> >> beschikbaar kan stellen?
> > 
> > ___
> > Talk-nl mailing list
> > Talk-nl@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-nl
> > 
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl




woonplaatsen.xslt
Description: application/xslt
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Fwd: Gebruikersvoorwaarden BAG niet meer van toepassing

[Gertjan Idema]

On Fri, 2012-09-21 at 21:54 +0200, Pander wrote:

> On 2012-09-21 14:23, Gertjan Idema wrote:
> > BAG bevat alleen woonplaatsen.
> > De nieuwste versie (in ieder geval vanaf 8-8-2012) bevat daarnaast een
> > bestand met de relatie tussen woonplaatsen en gemeenten
> > (GEM-WPL-RELATIE-08082012.zip)
> 
> Ah. Ja ik zie in de bestanden:
> 
> VBO08082012.zip Verblijfsobject (Woonfunctie/Industriefunctie, ...)
> STA08082012.zip Standplaats
> OPR08082012.zip Openbare Ruimte (Administratief
> gebied/Kunstwerk/Landschappelijk gebied/Spoorbaan/Terrein/Water/Weg)
> PND08082012.zip Pand
> LIG08082012.zip Ligging
> WPL08082012.zip Woonplaats
> NUM08082012.zip Nummeraanduiding (Postcode, Huisnummer, ...)
> GEM-WPL-RELATIE-08082012.zip Gemeente Woonplaats Relatie
> 

LIG staat voor ligplaats (van woonboten)

> > Zelf ben ik bezig met een osmosis plug-in voor BAG (uitgaande van de
> > PostGIS database die NLExtract produceert).
> > De Woonplaatsen import werkt inmiddels lokaal en produceert OSM
> > bestanden met woonplaats multipolygonen en de volgende tags:
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > (Voorbeeld voor woonplaats Utrecht)
> > 
> > Selectie kan op basis van (1 of meer) provincie, gemeente of woonplaats.
> > Hierbij kunnen de namen of de identificatiecodes gebruikt worden.
> > 
> > Ik moet nog het een en ander testen en documenteren voordat de plug-in
> > geschikt is voor algemeen gebruik.
> > 
> > Ook is het nodig om de tags voor BAG data te standaardiseren. Minimaal
> > zijn volgens mij de bag object identificatie (ref:woonplaatscode voor
> > woonplaatsen) en de bag extract versie. Ik gebruik nu
> > bag:extract=WPL08082012, maar dat zou bijvoorbeeld ook
> > bag:datum=08082012 kunnen zijn.
> > Voor panden ben ik al bag:pand_id en ref:bagid tegengekomen in tagwatch.
> > 
> > Een osmosis panden plug-in wordt de volgende stap.
> 
> Kunnen alle bovengenoemde bestanden aan elkaar gekoppeld worden om
> kaarten zoals http://www.nlextract.nl/gallerij/top10nl-jwvanaalst heeft
> te maken? Of missen er nog bestanden met onderlinge relaties?



De BAG bevat alleen gebouwen, ligplaatsen, staanplaatsen, adressen en
woonplaatsgrenzen. Voor de kaarten zoals JW die maakt heb je de top10nl
gegevens nodig. Die staan overigens voor zover ik weet helemaal los van
OpenStreetmap.


> > Gertjan Idema
> > 
> > 
> > 
> > On Fri, 2012-09-21 at 13:20 +0200, Pander wrote:
> >> On 2012-09-19 12:14, Minko wrote:
> >> > En zouden die techneuten dat evt ook op het forum willen delen, of is 
> >> > dat teveel gevraagd?
> >> > Zie http://forum.openstreetmap.org/viewtopic.php?pid=274222#p274222
> >>
> >> Op de volgende eenvoudige manier kan ik de woonplaatsen er uit halen:
> >>
> >> cat _*WPL*xml|sed -e 's/>\n >> 's///'|sed -e
> >> 's/<\/bag_LVC:woonplaatsNaam>//'|sed -e "s/'/'/g"|sed -e
> >> 's/â/â/g'|sed -e 's/ë/ë/g'|sed -e 's/û/û/g'|sort|uniq
> >>
> >> Maar hoe is te zien of het om een gemeente, woonplaats of buurtschap gaat?
> >>
> >> Kan ik dan beter met osmosis aan de slag gaan?
> >>
> >> > ZMW schreef:
> >> >> Is een een techneut die deze BAG data als transparant layer voor JOSM
> >> >> beschikbaar kan stellen?
> >> > 
> >> > ___
> >> > Talk-nl mailing list
> >> > Talk-nl@openstreetmap.org <mailto:Talk-nl@openstreetmap.org>
> >> > http://lists.openstreetmap.org/listinfo/talk-nl
> >> > 
> >>
> >>
> >> ___
> >> Talk-nl mailing list
> >> Talk-nl@openstreetmap.org <mailto:Talk-nl@openstreetmap.org>
> >> http://lists.openstreetmap.org/listinfo/talk-nl
> > 
> > 
> > 
> > ___
> > Talk-nl mailing list
> > Talk-nl@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-nl
> > 
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Fwd: Gebruikersvoorwaarden BAG niet meer van toepassing

[Gertjan Idema]

BAG bevat alleen woonplaatsen.
De nieuwste versie (in ieder geval vanaf 8-8-2012) bevat daarnaast een
bestand met de relatie tussen woonplaatsen en gemeenten
(GEM-WPL-RELATIE-08082012.zip)

Zelf ben ik bezig met een osmosis plug-in voor BAG (uitgaande van de
PostGIS database die NLExtract produceert).
De Woonplaatsen import werkt inmiddels lokaal en produceert OSM
bestanden met woonplaats multipolygonen en de volgende tags:








(Voorbeeld voor woonplaats Utrecht)

Selectie kan op basis van (1 of meer) provincie, gemeente of woonplaats.
Hierbij kunnen de namen of de identificatiecodes gebruikt worden.

 Ik moet nog het een en ander testen en documenteren voordat de plug-in
geschikt is voor algemeen gebruik.

Ook is het nodig om de tags voor BAG data te standaardiseren. Minimaal
zijn volgens mij de bag object identificatie (ref:woonplaatscode voor
woonplaatsen) en de bag extract versie. Ik gebruik nu
bag:extract=WPL08082012, maar dat zou bijvoorbeeld ook
bag:datum=08082012 kunnen zijn.
Voor panden ben ik al bag:pand_id en ref:bagid tegengekomen in tagwatch.

Een osmosis panden plug-in wordt de volgende stap.

Gertjan Idema



On Fri, 2012-09-21 at 13:20 +0200, Pander wrote:

> On 2012-09-19 12:14, Minko wrote:
> > En zouden die techneuten dat evt ook op het forum willen delen, of is dat 
> > teveel gevraagd?
> > Zie http://forum.openstreetmap.org/viewtopic.php?pid=274222#p274222
> 
> Op de volgende eenvoudige manier kan ik de woonplaatsen er uit halen:
> 
> cat _*WPL*xml|sed -e 's/>\n 's///'|sed -e
> 's/<\/bag_LVC:woonplaatsNaam>//'|sed -e "s/'/'/g"|sed -e
> 's/â/â/g'|sed -e 's/ë/ë/g'|sed -e 's/û/û/g'|sort|uniq
> 
> Maar hoe is te zien of het om een gemeente, woonplaats of buurtschap gaat?
> 
> Kan ik dan beter met osmosis aan de slag gaan?
> 
> > ZMW schreef:
> >> Is een een techneut die deze BAG data als transparant layer voor JOSM
> >> beschikbaar kan stellen?
> > 
> > ___
> > Talk-nl mailing list
> > Talk-nl@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-nl
> > 
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] http://www.waarismijnstembureau.nl

[Gertjan Idema]

On Wed, 2012-09-12 at 16:00 +0200, Stefan de Konink wrote:

> On 09/12/12 13:58, Reinder Verlinde wrote:
> > De kaart op http://www.waarismijnstembureau.nl toont default een OSM 
> > laag. Toch staat ook daar onderin een Google-logo. Ik zie nergens een 
> > OSM-attributie.
> 
> Het met het feit dat er "OSM" als naam op de laag staat (rechts
> bovenin), is aan de attributie toch voldaan?
> Stefan
> 

Volgens de OSM gebruiksvoorwaarden is dat niet voldoende:

-Je voldoet aan de licentievoorwaarden als je de volgende tekst,
inclusief werkende hyperlinks, bij een herpublicatie of afgeleid werk op
neemt:

-Data by OpenStreetMap.org contributors under CC BY-SA 2.0 license.

-Overigens loopt er op dit moment een discussie binnen de OpenStreetMap
gemeenschap die mogelijk leidt tot een verandering van de licentie. De
nieuwe licentie wordt mogelijk de Open Database Licentie.

Dat laatste zinnetje heb ook maar even gekopieerd omdat ik denk dat de
tekst niet helemaal up-to-date is.

Overigens weer eens wat anders om de blauwe Google Streetview  lijntjes
op een OSM achtergrond te zien. Dat krijg je als je OSM tiles in Google
maps software plakt.
De app is trouwens 'gebouwd' door Centric.

Gertjan




> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Nieuwe maximumsnelheden op snelwegen

[Gertjan Idema]

Die 130 lijkt mij een politieke gril die zo weer overgewaaid is. Ik zou
er niet te veel energie in steken.

Gertjan

On Mon, 2012-09-03 at 20:42 +0200, Colin Smale wrote:

> Het heeft onze regering behaagd om de snelheidslimieten op 's lands 
> autosnelwegen aan te passen. Helaas is het er niet makkelijker op 
> geworden; vroeger had je 120 met een paar uitzonderingen, tegenwoordig 
> moet je rekening houden met verschillende scenario's, elk met eigen 
> bebording.
> 
> Met het volgende ben ik me ervan bewust dat ik het risico loop om 
> gelyncht te worden wegens het willen standardiseren van de tagging...
> 
> Het lijkt mij zinvol om enige gelijkvormigheid in de tagging na te 
> streven. De drie scenario's zijn afhankelijk van tijdstip en het al dan 
> niet open zijn van een eventuele spitsstrook. Laat ik even de discussie 
> aanzwengelen met het volgende voorstel, waarbij ik gebruik maak van het 
> voorstel voor "uitgebreide toegangskenmerken" zoals beschreven op de 
> volgende pagina: 
> http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags
> 
> 1) Vaste maximumsnelheid
>  maxspeed=X
> 2) 130 bij nacht, 120/100 overdag
>  maxspeed=130
>  maxspeed:(06:00-19:00)=120
> 3) 130 bij nacht, 120/100 overdag bij gesloten spitsstrook; 100 bij 
> geopende spitsstrook
>  maxspeed=130
>  maxspeed:(06:00-19:00)=120
>  maxspeed:spitsstrook=100
> 
> De snelheid bij geopende spitsstrook is een probleem omdat de tijden 
> niet voorspelbaar zijn. Wie heeft hiervoor een oplossing?
> 
> Colin
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Fouten in labels

[Gertjan Idema]

Los van het belang van snacks, vraag ik mij af of het de ambitie moet
zijn om alle OSM tags te relateren aan de OpenTaal database.
Mijn insteek zou zijn om het in eerst instantie te beperken tot de
'name' en 'name:nl' tags.
Hierin zou je volgens mij alle toponiemen moeten kunnen vinden.
Voor de 'name' tag hoort hier vervolgens een restrictie voor
nederlandstalig grondgebied bij.

Gertjan

On Mon, 2012-06-04 at 12:00 +0200, Pander wrote:

> On 2012-06-04 11:37, Floris Looijesteijn wrote:
> > Cool, maar bitterballen=yes is mijns inziens geen 'fout'.
> > bitterballen=no zou voor mij en m'n collega's een reden zijn een
> > andere kroeg te zoeken.
> 
> Is snacks=yes een goed alternatief? Verder staat er ook nog een
> kroket=yes. Overigens komen bitterballen en kroket maar een keer voor.
> Frikadel staat helaas nog niet op OpenStreetMenu. ;)
> 
> > Normaal gesproken zou de tag engels moeten zijn maar gezien diverse
> > zeer creatieve vertalingen op engelstalige kaarten denk ik niet dat we
> > daar uit gaan komen :)
> > 
> > Groet,
> > Floris Looijesteijn
> > 
> > 2012/6/4 Pander :
> >> Hoi allemaal,
> >>
> >> Los van de discussie over hoe OpenTaal toponiemen uit OSM kan gebruiken
> >> hebben mijn filters al wel het een en ander ter verbetering gevonden.
> >>
> >> In http://www.pastebay.net/1062450 is een histogram te vinden van de
> >> labels. Voor labels die niet meer dan vijf keer voorkomen worden ook de
> >> desbetreffende waarden getoond.
> >>
> >> Er zitten een paar fouten in die gerepareerd kunnen worden. Enkele
> >> voorbeelden zijn:
> >> - Adriaanse
> >> - Atletiekbaan
> >> - Buurtbussen standplaats
> >> - Hotel
> >> - rcn_ref#
> >> en er zittten ook wat leuke /foutjes/ tussen zoals:
> >> - bitterballen = yes
> >> - broodje = kaassouflé met mayonaise
> >> - gezellig = yes
> >>
> >> De waarden met &#; bevatten UTF-8-karakters die pastebay helaas niet
> >> ondersteunt, die kunnen genegeerd worden. Let op, dit overzicht wordt
> >> over een maand automatisch verwijderd. Graag ontwikkel ik het script
> >> verder met iemand van de OSM community zodat regelmatig geautomatiseerde
> >> rapporten geeft over mogelijke fouten.
> >>
> >> Groetjes,
> >>
> >> Pander
> >>
> >> ___
> >> Talk-nl mailing list
> >> Talk-nl@openstreetmap.org
> >> http://lists.openstreetmap.org/listinfo/talk-nl
> > 
> > ___
> > Talk-nl mailing list
> > Talk-nl@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-nl
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Andere tijden

[Gertjan Idema]

Is er iemand die hier iets zinnig over kan zeggen?

- Is het voldoende om 'source:name=opentaal.org' toe te voegen aan namen
die met behulp de OpenTaal database gecorrigeerd zijn?
- Onder welke voorwaarden mogen geografische namen uit OpenStreetMap
overgenomen worden in de OpenTaal database?
- Stel ik maak een database met namen die in OSM voor komen en niet in
OpenTaal, of andersom; wat voor licentie heeft die database dan?
- Geldt 'source=AND' ook voor de name tag van een straat?
- Zo ja, mag deze straatnaam dan met vermelding van 'AND' als source
naar OpenTaal gestuurd worden.

Zelf wordt ik, net als waarschijnlijk de meesten van jullie, erg moe van
dit soort vragen.
Ik hoop echter dat er iemand is die ze kan beantwoorden en dat het
antwoord een vruchtbare samenwerking met OpenTaal niet in de weg staat.

Met vriendelijke groeten,
Gertjan Idema

PS. Mijn (OpenTaal gebaseerde) spellingchecker herkent in dit mailtje
wel het woord 'OpenTaal', maar niet 'OpenStreetMap'
  voor een vruchtbare samenwerking lijkt het mij wenselijk dat de term
'OpenStreetMap' wordt opgenomen in de OpenTaal database ;-).
 Weet iemand of 'OpenStreetMap' met drie hoofdletters de juiste spelling
is? 


On Thu, 2012-05-24 at 20:15 +0200, Stefan de Konink wrote:

> On 24-05-12 10:29, Pander wrote:
> > Ik ga een dezer dagen weer verder met de labelextractie van de
> > Nederlandse OSM om toponiemen toe te voegen aan de woordenlijst van
> > OpenTaal.
> 
> Mag jij dit doen van jouw juristen en die van de OpenStreetMap 
> Foundation? Want jouw licentie is niet de ODBL. Dit voorkomt ook dat 
> openOV actief data in OpenStreetMap stopt, omdat wijzigingen er niet 
> uitgehaald mogen worden onder een andere licentie.
> 
> Stefan
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Andere tijden

[Gertjan Idema]

Don't kill the messenger zou ik zeggen.

We zitten nu eenmaal (binnenkort althans) met de nieuwe licentie
opgescheept. Leuk is anders, maar het zij zo.
Licenties zijn voor bijna iedereen complexe materie, waardoor het
verleidelijk wordt om er lak aan te hebben.
Zelf kan ik die verleiding weerstaan door de wetenschap dat schending
van de licentie grote consequenties kan hebben voor het voortbestaan van
OpenStreetmap.
Vanwege dat belang vind ik het ook goed om anderen daarop te wijzen.

Ik vind het geen stijl om iemand daarop aan te vallen, en al helemaal
niet iemand die hard heeft gevochten voor een minder stringente
licentie.

Met vriendelijke groeten,

Gertjan Idema


On Fri, 2012-05-25 at 22:38 +0200, Robert Elsenaar wrote:

> Stefan, weinigen interesseert al dat licentie gedoe. Misschien ken jij
> 10CC. Van CC-0 hebben echt weinigen gehoord. Welk genre is dat? Snapje
> het nou?
> 
> 
> Met vriendelijke groeten,
> Robert Elsenaar 
> (Verzonden vanaf Mobile) 
> 
> 
> Stefan de Konink  schreef:
> 
> 
> On 25-05-12 08:40, Robert Elsenaar wrote:
> > Nee, maar daar gaat het niet om. Alleen op ieder moment dat er een
> nieuw
> > initiatief is, begin jij direct te z... over licentievoorwaarde. A)
> > iedereen weet best wel dat je ook faar tijdens het proces naar moet
> > kijken. B) Henk (foundation) is onze licentie sheriff en die heeft
> heus
> > geen overijverige assistent nodig.
> 
> Waarom worden mijn ideeën waar ik vooraf over in overleg ga met de 
> foundation dan de grond in gefietst, en hoor je er niemand meer over
> bij 
> een ander project.
> 
> In dat geval kan iedereen dus gewoon doen wat hij goed dunkt - mij
> maakt 
> het niet uit, immers mijn data is CC-0.
> 
> 
> Stefan
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Openrouteservice bruikbaar?

[Gertjan Idema]

Hallo Paul,

Er is een travelingsales project voor OSM:
http://sourceforge.net/projects/travelingsales/

Zelf heb ik er geen ervaring mee, maar ben wel nieuwsgierig naar je
bevindingen.

Gertjan Idema

On Mon, 2012-03-19 at 15:53 +0100, Paul van der Vlis wrote:

> Hallo,
> 
> Voor een kringloopbedrijf zoek ik een alternatief voor "autoroute".
> Ze moeten b.v. 20 adressen plannen, en uitrekenen wat de beste route is.
> 
> Is http://openrouteservice.org/  bruikbaar voor hen?
> 
> Om eerlijk te zijn zie ik helemaal geen route, en ook geen beschrijving.
> Maar wel steeds meldingen als "Please set 'Start' point!" terwijl ik dat
> gezet heb (zou het kunnen dat een erg nieuwe browser nodig is?).
> 
> Groet,
> Paul.
> 
> 
> 


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Balletje: Beheer openbare ruimte?

[Gertjan Idema]

De site http://www.verbeterdebuurt.nl doet ook zoiets.
Utrecht doet mee en ik heb het idee dat er redelijk snel op gereageerd
wordt door de gemeente.

Gertjan


On Sat, 2012-02-04 at 09:07 +0100, Christ van Willegen wrote:

> Hoi allemaal,
> 
> Ik vroeg me af of het voor gemeenten, in navolging van onze eigen
> 'openstreetbugs', een aanvulling voor hun beheer openbare ruimte zou
> zijn als burgers ergens een marker op de kaart zouden kunnen zetten
> met 'boom omgevallen' of 'container vol' oid.
> 
> Gemeenten zouden dan een 'abonnenment' kunnen nemen op een bep. gebied
> waarna er mails (oid) gestuurd worden als er iets in dat gebied
> gebeurt.
> 
> Ja, biedt wel kans tot misbruik, helaas... maar als je een en ander
> van de 'aangever' logt en dat erbij vermeldt, dan zal het in ieder
> geval wel opvallen als er vaak achter elkaar iets gemeld wordt.
> 
> Groeten,
> 
> Christ van Willegen
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Leidsche Rijntunnel (A2 Utrecht) wordt eindelijk in gebruik genomen

[Gertjan Idema]

Voor mij ziet het er nog steeds goed uit.
Omdat het een tunnel is, is het wel wat minder opvallend als een blauwe
snelweg.

Gertjan

On Mon, 2012-01-30 at 11:07 +0100, Floris Looijesteijn wrote:

> Is het gerevert ofzo?
> 
> Of loopt de rendering achter?
> 
> http://osm.org/go/0E6Dnlli-
> 
> Groet,
> Floris
> 
> 2012/1/28 Frank Steggink :
> > Goede zaak, nu lopen we mijlenver voor op de kaartjesconcurrent, die de
> > vorige, verouderde situatie zelfs niet goed had! Viva crowdsourcing :)
> >
> > Frank
> >
> > On 28-1-2012 19:10, Colin Smale wrote:
> >>
> >> Hij is open! Ben er net twee keer doorheen gereden. Ik heb de tunnel in
> >> OSM al "geopend", samen met de nieuwe afrit 8 die ook al open is. Ik ga
> >> straks even een viertal GPS tracks ertegenaan leggen.
> >>
> >> De oude, tijdelijke rijbaan ligt er natuurlijk nog steeds, en is zelfs nog
> >> een klein beetje open middels een doorsteek van de hoofdrijbaan voor 
> >> verkeer
> >> vanuit Breukelen naar Utrecht-Centrum moet (want de parallelrijbaan is
> >> t.h.v. Maarssen nog eventjes gesloten). Ik geloof dat het de bedoeling is
> >> dat de situatie na dit weekend redelijk op de definitieve zal lijken - dan
> >> zal die doorsteek ook weg zijn. Op dit moment heb ik de oude rijbaan
> >> omgetagd in "service" maar afhankelijk van hoe het er maandag uitziet kan
> >> die weg of naar "construction" of wat dan ook.
> >>
> >> Colin
> >>
> >> On 24/01/2012 19:26, Frank Steggink wrote:
> >>>
> >>> Voor wie het heeft gemist, binnenkort zal eindelijk een stuk
> >>> highway=construction; construction=motorway van de kaart [1] verdwijnen en
> >>> worden omgezet naar een highway=motorway. Vorige week is besloten om de
> >>> Leidsche Rijntunnel in gebruik te nemen. Zie [2] voor meer info. De hoofd-
> >>> en parallelbanen zullen gefaseerd in gebruik worden genomen, te beginnen 
> >>> met
> >>> de meest westelijke tunnelbuis (lokaal verkeer van noord naar zuid). Deze
> >>> wordt a.s. weekend aangepast, zodat deze geopend kan worden. De overige
> >>> weekenden zijn 17 t/m 20 februari, 13 t/m 16 april en 15 t/m 18 juni.
> >>>
> >>> Als iemand in de buurt van Utrecht in de gelegenheid is de situatie te
> >>> checken na a.s. weekend, dan graag. Mij gaat het pas het weekend erop
> >>> lukken.
> >>>
> >>> Groeten,
> >>>
> >>> Frank
> >>>
> >>>
> >>> [1] http://osm.org/go/0E6Dnlli-
> >>> [2]
> >>> http://rijkswaterstaat.nl/actueel/nieuws_en_persberichten/2012/januari2012/a2_leidsche_rijntunnel_in_vier_weekenden_geopend_start_eind_januari.aspx
> >>>
> >>> ___
> >>> Talk-nl mailing list
> >>> Talk-nl@openstreetmap.org
> >>> http://lists.openstreetmap.org/listinfo/talk-nl
> >>
> >>
> >>
> >> ___
> >> Talk-nl mailing list
> >> Talk-nl@openstreetmap.org
> >> http://lists.openstreetmap.org/listinfo/talk-nl
> >>
> >
> >
> > ___
> > Talk-nl mailing list
> > Talk-nl@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-nl
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Leidsche Rijntunnel (A2 Utrecht) wordt eindelijk in gebruik genomen

[Gertjan Idema]

On Tue, 2012-01-24 at 20:14 +0100, Colin Smale wrote:
> Ik ga zondag even op verkenning, en maandag nog een keer onder weg naar 
> m'n werk. Ik ben ook benieuwd of dan de nieuwe afrit 8 gelijk in gebruik 
> wordt genomen.
> 
> Colin

Ik kom er 4 keer in de week langs, maar kan misschien niet zoveel zien
omdat ik dan al in de tunnel zit. Hopelijk is de (her)nieuwe afrit 8 dan
al in gebruik, anders kom ik er niet vanaf de parallelbaan en moet ik
doorrijden naar Oudenrijn.
Als het nodig is voor meer informatie rijd ik nog wel een keertje apart
heen.

Gertjan

> On 24/01/2012 19:26, Frank Steggink wrote:
> > Voor wie het heeft gemist, binnenkort zal eindelijk een stuk 
> > highway=construction; construction=motorway van de kaart [1] 
> > verdwijnen en worden omgezet naar een highway=motorway. Vorige week is 
> > besloten om de Leidsche Rijntunnel in gebruik te nemen. Zie [2] voor 
> > meer info. De hoofd- en parallelbanen zullen gefaseerd in gebruik 
> > worden genomen, te beginnen met de meest westelijke tunnelbuis (lokaal 
> > verkeer van noord naar zuid). Deze wordt a.s. weekend aangepast, zodat 
> > deze geopend kan worden. De overige weekenden zijn 17 t/m 20 februari, 
> > 13 t/m 16 april en 15 t/m 18 juni.
> >
> > Als iemand in de buurt van Utrecht in de gelegenheid is de situatie te 
> > checken na a.s. weekend, dan graag. Mij gaat het pas het weekend erop 
> > lukken.
> >
> > Groeten,
> >
> > Frank
> >
> >
> > [1] http://osm.org/go/0E6Dnlli-
> > [2] 
> > http://rijkswaterstaat.nl/actueel/nieuws_en_persberichten/2012/januari2012/a2_leidsche_rijntunnel_in_vier_weekenden_geopend_start_eind_januari.aspx
> >
> > ___
> > Talk-nl mailing list
> > Talk-nl@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-nl
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl



___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Straatnamen uit BAG vergelijken met OSM

[Gertjan Idema]

On Sat, 2012-01-21 at 23:45 +0100, Stefan de Konink wrote:
> > Ja, maar geen geometrieen als je dat bedoelt. Deze tabel bevat
> > alleen namen in combinatie met woonplaats. Aan een 'Rijksweg A12'
> > record heb je in mijn ogen dan ook weinig.
> 
> Mmm.. das toch een ingang voor iets anders. Want als ik een openbare
> ruimte naam nu eens zou kunnen koppelen aan een NWB wvk_id, of aan
> iets in Top10...

De openbareruimte tabel moet via woonplaatscode en straatnaam aan het
NWB. Hetzij via een woonplaatscode->gemeentecode table, hetzij via een
woonplaatscode->woonplaatsnaam table. Vraag is natuurlijk, hoe goed de
straatnamen in NWB overeenkomen met de BAG straatnamen. Die tabellen ga
ik binnenkort maar eens naast elkaar leggen.
Wat hoop je hiermee uiteindelijk te kunnen bereiken?

Gertjan


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Straatnamen uit BAG vergelijken met OSM

[Gertjan Idema]

On Sat, 2012-01-21 at 19:53 +0100, Stefan de Konink wrote:

> Op 21-01-12 19:41, Gertjan Idema schreef:
> > Overigens bevat de BAG ook straatnamen zonder huizen, zoals 
> > 'Waterlinieweg' of 'Rijksweg A12'. De laatste heeft dan wel per
> > gemeente een andere code en het zal per gemeente verschillen hoe
> > compleet deze data is.
> 
> En dit staat ook in de openbare ruimte tabel?
> 
Ja, maar geen geometrieen als je dat bedoelt. Deze tabel bevat alleen
namen in combinatie met woonplaats. Aan een 'Rijksweg A12' record heb je
in mijn ogen dan ook weinig.

Gertjan


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Straatnamen uit BAG vergelijken met OSM

[Gertjan Idema]

On Sat, 2012-01-21 at 18:02 +0100, Cartinus wrote:

> Er zitten geen straten in de BAG. Dus wat zou je dan in ref:BAG willen
> zetten als er meer gebouwen in een straat staan? Volgens mij hoort BAG
> data op de gebouwen te zitten.
Straten vallen in de BAG in de categorie openbare ruimte (evenals
bijvoorbeeld bruggen en parken).
Iedere straat in de BAG heeft daarbij een eigen identificatiecode.
034430003369 staat voor het Domplein in Utrecht. Deze code zou je
dus aan de bijbehorende straat(delen) kunnen koppelen. Net zoals
ref:woonplaatscode voor woonplaatsen, ref:gemeentecode voor gemeenten,
en ISO3166-1 voor landen. (ref:provinciecode of ISO3166-2 zijn er niet) 

Overigens bevat de BAG ook straatnamen zonder huizen, zoals
'Waterlinieweg' of 'Rijksweg A12'. De laatste heeft dan wel per gemeente
een andere code en het zal per gemeente verschillen hoe compleet deze
data is.

Gertjan


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Straatnamen uit BAG vergelijken met OSM

[Gertjan Idema]

Ik kom inderdaad morgen ook. Dat er een BAG overleg is wist ik niet,
maar daar wil ik wel bij zijn.

Gertjan

On Sat, 2012-01-21 at 17:11 +0100, Stefan de Konink wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Op 21-01-12 16:58, Gertjan Idema schreef:
> > Dit roept een aantal vragen op: - Mogen de straatnamen uit de BAG
> > als leidend worden beschouwd?
> 
> Ja, als ze pertinent niet kloppen moet je ze eigenlijk terugmelden.
> Straatnamen haal je denk ik uit de huizen langs de weg. Mogelijk kan
> het NWB je meer op weg helpen om de overige 300 te vinden. Immers: de
> BAG heeft geen straten (en dus geen postcodes voor straten) waar geen
> adressen aan verbonden zijn.
> 
> > - Is er een reden om geen diakritische teken (accenten, cedille
> > etc.) te gebruiken in OSM, of komt dat uit de AND import?
> 
> Ik vermoed het laatste, maar OSM is ooit ook wel eens heel erg
> moeilijk geweest met omzetten van vreemde tekens.
> 
> > - Heeft het zin om iets als ref:BAG toe te voegen aan straten?
> 
> Mijn suggestie zou hier zijn, hang BAG aan huizen, (of eventueel
> source: BAG aan straten) en gebruik een ref:nlnwb = gid voor
> semantische koppeling.
> 
> > - Wat te denken van een BAG plug-in in OSM om straatnamen te 
> > controleren, of BAG identificatiecodes toe te voegen?
> 
> Liever zoals eerder voorgesteld niet een plugin, maar iets dat iedere
> maand gedraad kan worden. Ik hoorde van Frank dat jij morgen ook kwam,
> morgen is er in ieder geval BAG overleg ;)
> 
> 
> Stefan
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.18 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEAREKAAYFAk8a48AACgkQYH1+F2Rqwn2OfACeLHYDILRiFsqpn9fN6UACWIGJ
> oVwAoIOXrTl70bKlCdDPMZRUmoXCBo9w
> =prlE
> -END PGP SIGNATURE-
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

[OSM-talk-nl] Straatnamen uit BAG vergelijken met OSM

[Gertjan Idema]

Vandaag heb ik de straatnamen uit een BAG extract eens naast de OSM
straatnamen gelegd.
Te beginnen mijn eigen woonplaats (Utrecht).
Een eerste analyze leert dat ruim 300 straten (van in totaal zo'n 3000)
alleen in OSM voorkomen en ruim 400 alleen in BAG.
Ruim de helft hiervan kom door verschillen in de spelling (hoofdletters,
spaties, accenten afkortingen)
Van de rest betreft een klein gedeelte kunstmatige-straten
(Dienstingang, Knooppunt Lunetten, Parkeerplaats tuincentrum,
Playground Marco Polo).
Het overige zijn straten die in een van beide databases niet voorkomen.
Niet alleen uit de nieuwbouwwijk Leidsche Rijn,
maar ook uit oudere stadsdelen.

Dit roept een aantal vragen op:
- Mogen de straatnamen uit de BAG als leidend worden beschouwd?
- Is er een reden om geen diakritische teken (accenten, cedille etc.) te
gebruiken in OSM, of komt dat uit de AND import?
- Heeft het zin om iets als ref:BAG toe te voegen aan straten?
- Wat te denken van een BAG plug-in in OSM om straatnamen te
controleren, of BAG identificatiecodes toe te voegen?

Ik ben benieuwd naar jullie reacties.

Gertjan Idema
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] probleem met zip files van dev.openstreetmap.nl

[Gertjan Idema]

Af en toe ga je wat snel Stefan, voor ons gewone stervelingen ;-)

Als ik het goed begrijp heb je gzip encoding uitgezet op de server,
waardoor iedereen weer kan downloaden, maar zonder het snelheidsvoordeel
van compressie.

Uit wat ik op Internet vind, maak ik op dat de combinatie Cherokee,
gzip, Internet Explorer
niet lekker werkt, maar of dit aan IE of Cherokee ligt, wordt niet echt
duidelijk.
Volgens de release-notes van Cherokee wordt gzip uitgezet voor oudere IE
versies
(http://lists.octality.com/pipermail/cherokee-announce/2011-October/69.html),
maar het lijkt erop dat dat niet voldoende is.

Voorlopig hebben we in ieder geval een werkbare oplossing.

Gertjan

On Sun, 2012-01-15 at 21:31 +0100, Stefan de Konink wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Op 15-01-12 21:13, Minko schreef:
> > Kan je ook uitleggen wat je nu hebt aangepast?
> 
> Exact wat ik zei dat je in een bugreport naar Microsoft moest sturen.
> 
> > Dan hoef ik de hele mailinglijst niet af te zoeken, ik zou niet
> > weten waar ik het moest zoeken.
> 
> Maar grote kans dat je een virusscanner aan hebt staan, welke je niet
> met ons hebt gedeeld. Want het hele internet stroomt over van deze
> meldingen.
> 
> 
> Stefan
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.18 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEAREKAAYFAk8TN5sACgkQYH1+F2Rqwn3k8QCeIdWMJXveePs7q479Uzxqxlhl
> 9J4AmgKoFcKRi0OdIqfd55ZgyN7kbZwg
> =ltHJ
> -END PGP SIGNATURE-
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

[OSM-talk-nl] Kandinskystraat, Leidsche Rijn

[Gertjan Idema]

Deze straat zit nog niet in OSM. Vlak daarbij ontbreekt de naam van de
Marc Chagall straat en zijn OSM en Google
het niet eens over waar de Picassostraat over gaat in de Willinkstraat.
Als nog eens in die buurt ben, zal ik de laatste twee nagaan. 
Ik heb echter (shame on me) geen GPS, dus straten toevoegen wordt
lastig.

Gertjan
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

[OSM-talk-nl] Semi automatisch BAG voorstel

[Gertjan Idema]

Beste mensen,

Wat is op dit moment de status van deze Thread?
Ik ben samen met It's so funny (Johan) aan het kijken naar de
mogelijkheid om de woonplaatsgrenzen
uit BAG te gebruiken om deze in Osm te verbeteren. 
Daarbij willen we echter geen andere projecten doorkruisen.

Gertjan Idema
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl