Re: [OSM-talk-nl] tile.openstreetmap.nl
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?
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
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
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
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 g.id...@zonnet.nl 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
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 g.id...@zonnet.nl 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
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 met links
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 g.id...@zonnet.nl 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=tourismzoom=17lat=51.91319lon=4.47294layers=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
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 ?xml version=1.0? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:template match=/ html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en head meta http-equiv=content-type content=text/html; charset=utf-8 lang=en/ titleOSM3S Response/title /head body h2POIs/h2 xsl:apply-templates/ /body /html /xsl:template xsl:template match =osm/node | osm/way | osm/relation p !-- De naam van het object indien aanwezig -- xsl:if test=tag[@k='name'] strongxsl:value-of select=tag[@k='name']/@v/br//strongxsl:text#10;/xsl:text /xsl:if !-- De link naar het object op openstreetmap.org -- a target=_blankxsl:attribute name=hrefhttp://www.openstreetmap.org/browse/xsl:value-of select=name()//xsl:value-of select=@id//xsl:attributexsl:value-of select=name()/xsl:text /xsl:textxsl:value-of select=@id//abr/xsl:text#10;/xsl:text xsl:apply-templates select=tag/ /p /xsl:template !-- Behandeling van gewone tags -- xsl:template match =tag xsl:value-of select=@k/: xsl:value-of select=@v/br/xsl:text#10;/xsl:text /xsl:template !-- wikipedia -- xsl:template match =tag[@k='wikipedia'] xsl:variable name=wikixsl:value-of select=@v//xsl:variable Wikipedia: a target=_newxsl:attribute name=hrefhttp://xsl:value-of select=substring($wiki, 1, 2)/.wikipedia.org/wiki/xsl:value-of select=substring($wiki, 4)/ /xsl:attributexsl:value-of select=@v//abr/xsl:text#10;/xsl:text /xsl:template !-- website -- xsl:template match =tag[@k='website'] Website: a target=_newxsl:attribute name=hrefxsl:value-of select=@v//xsl:attributexsl:value-of select=@v//abr/xsl:text#10;/xsl:text /xsl:template !-- twitter -- xsl:template match =tag[@k='twitter' or @k='contact:twitter'] Twitter: a target=_newxsl:attribute name=hrefhttp://www.twitter.com/xsl:value-of select=@v//xsl:attributexsl:value-of select=@v//abr/xsl:text#10;/xsl:text /xsl:template !-- url -- xsl:template match =tag[@k='url'] URL: a target=_newxsl:attribute name=hrefxsl:value-of select=@v//xsl:attributexsl:value-of select=@v//abr/xsl:text#10;/xsl:text /xsl:template !-- molendatabase -- xsl:template match =tag[@k='mdb_id'] Molendatabase: a target=_newxsl:attribute name=hrefhttp://www.molendatabase.nl/nederland/molen.php?nummer=xsl:value-of select=@v//xsl:attributexsl:value-of select=@v//abr/xsl:text#10;/xsl:text /xsl:template !-- molens.nl -- xsl:template match =tag[@k='dhm_id'] De hollandsche molen: a target=_newxsl:attribute name=hrefhttp://www.molens.nl/site/dbase/molen.php?mid=xsl:value-of select=@v//xsl:attributexsl:value-of select=@v//abr/xsl:text#10;/xsl:text /xsl:template xsl:template match =text()/ /xsl:stylesheet 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
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] Wikipedia
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] Wijken in Nederland
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
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
@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=90error=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
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=90error=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
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
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=WFSrequest=GetCapabilitiesversion=1.1.0
DescribeFeatureType:
http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs?service=WFSrequest=DescribeFeatureTypeversion=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 nouws...@xs4all.nl:
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
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 talk-nl-requ...@openstreetmap.org: 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
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.08095lon=5.124964zoom=18layers=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] BAG gegevens Re: OSM Navigatieapparatuur
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.318867lon=5.995507zoom=18layers=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
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 g.id...@zonnet.nl 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.08095lon=5.124964zoom=18layers=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
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.08095lon=5.124964zoom=18layers=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] Multi poligons
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.2113lon=4.57431zoom=17layers=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)
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): AlteveerAlteveer gem Hoogeveen BotlekBotlek Rotterdam De Hoefde Hoef De Luttede Lutte Den Haag's-Gravenhage De Woudede Woude ElstElst Ut EuropoortEuropoort Rotterdam HoogvlietHoogvliet Rotterdam MaasvlakteMaasvlakte Rotterdam PernisPernis Rotterdam 's-HertogenboschDen Bosch UrsemUrsem gem. S VondelingenplaatVondelingenplaat 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 officiële documenten gebruikt word, ik denk niet dat gemeente of provincie hints in de woonplaats naam onderdeel zijn van de officiële naam zoals op briefpapier van het stadsbestuur word gebruikt, op de plaatsnaamborden staat, en wat men in het postadres zou gebruiken. Het lijkt mij deze deze in het verleden zijn toegevoegd zodat om unique contraints in een database gewerkt kon worden, of om simpelweg in de oude kaartenbakken op basis van de naam het onderscheid te kunnen zien. Het hergebruiken van bestaande tags maar deze anders interpreteren voor een nieuw project zorgt voor nodeloze verwarring bij diegenen die bekent zijn met de originele insteek. Om dit te voorkomen kunnen we misschien beter onze eigen tag introduceren zodat we vrij zijn deze te definiëren. Zodoende voel ik er ook wel wat voor om bag:name of bag:woonplaatsnaam te gebruiken voor de naam zoals het in de BAG staat. Deze namespace is vrij voor ons om invulling te geven, en zullen minder snel aangepast worden als de name tag. Ik zie ook liever Alteveer op de kaart dan Alteveer gem
Re: [OSM-talk-nl] OSM in RD tiles
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.9777lon=4.001zoom=14layers=M
Een screenshot van mijn lokale server is te vinden op:
http://osm.peterse-uithuizen.com/~peter/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
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.9777lon=4.001zoom=14layers=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] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)
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): AlteveerAlteveer gem Hoogeveen BotlekBotlek Rotterdam De Hoefde Hoef De Luttede Lutte Den Haag's-Gravenhage De Woudede Woude ElstElst Ut EuropoortEuropoort Rotterdam HoogvlietHoogvliet Rotterdam MaasvlakteMaasvlakte Rotterdam PernisPernis Rotterdam 's-HertogenboschDen Bosch UrsemUrsem gem. S VondelingenplaatVondelingenplaat 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 verouderd is. Dat is nogal verwarrend. Huidige status: multipolygon=2173x, boundary=327x Een van de JOSM ontwikkelaars pushed de standaardisatie naar
Re: [OSM-talk-nl] Wegaanpassingen via www.staatscourant.nl
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 g.id...@zonnet.nl 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 ste...@konink.de schreef: On Tue, 1 Jan 2013, Robert Elsenaar wrote: Is mijn indruk correct dat er steeds meer data wel beschikbaar is en geschikt voor verwerking in OSM, maar dat geautomatiseerd robotisch toevoegen van deze gegevens of niet mogelijk of onwenselijk is? Nouja ik ben wel eens bij een bespreking van IM 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
Re: [OSM-talk-nl] Wegaanpassingen via www.staatscourant.nl
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 ste...@konink.de schreef: On Tue, 1 Jan 2013, Robert Elsenaar wrote: Is mijn indruk correct dat er steeds meer data wel beschikbaar is en geschikt voor verwerking in OSM, maar dat geautomatiseerd robotisch toevoegen van deze gegevens of niet mogelijk of onwenselijk is? Nouja ik ben wel eens bij een bespreking van IM 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
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
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 VD 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] Het taggen van BAG data.
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 g.id...@zonnet.nl 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. 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
Re: [OSM-talk-nl] Het taggen van BAG data.
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
nummeraanduidingen. Een pand kan meerdere verblijfsobjecten bevatten.
Ja het meestvoorkomende, maar ook omgekeerd (meerdere Panden bij VBO),
maar moet daarvan nog voorbeeld zien.
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
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. 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 invoeren, zie ik dat nog niet zo snel gebeuren. De osmosis plug-in waarmee ik bezig ben bied een optie om associatedstreet relaties te genereren, inclusief BAG openbareruimte id. Vanwege de complexiteit bij het invoeren zijn we er echter vanaf gestapt om die te gebruiken. Ook ruudblank en rullzer lijken geen associatedstreet relaties toe te voegen. 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
Re: [OSM-talk-nl] Het taggen van BAG data.
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.
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 o...@floris.nu 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 g.id...@zonnet.nl 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 OSM en straten uit andere bronnen. Dat gaat echter alleen werken associatedStreets gemeengoed zijn. Gezien de complexiteit bij het invoeren, zie ik dat nog niet zo snel gebeuren. De osmosis plug-in waarmee ik bezig ben bied een optie om associatedstreet relaties te genereren, inclusief BAG openbareruimte id
[OSM-talk-nl] Het taggen van BAG data.
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
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
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/g'|grep woonplaatsNaam|sed -e 's/bag_LVC:woonplaatsNaam//'|sed -e 's/\/bag_LVC:woonplaatsNaam//'|sed -e s/apos;/'/g|sed -e 's/#226;/â/g'|sed -e 's/#235;/ë/g'|sed -e 's/#251;/û/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] http://www.waarismijnstembureau.nl
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
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
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 pan...@opentaal.org: 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
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 ste...@konink.de 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] Andere tijden
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] Openrouteservice bruikbaar?
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] Leidsche Rijntunnel (A2 Utrecht) wordt eindelijk in gebruik genomen
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 stegg...@steggink.org: 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
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
[OSM-talk-nl] Straatnamen uit BAG vergelijken met OSM
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] Straatnamen uit BAG vergelijken met OSM
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
Re: [OSM-talk-nl] Straatnamen uit BAG vergelijken met OSM
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
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
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] probleem met zip files van dev.openstreetmap.nl
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
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
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
