[OSM-talk-nl] Aankondiging mini-seminar RD en Open Source Software
Hoi, Wellicht is dit voor een aantal van jullie ook interessant, ondanks dat je niet op de OSGeo-mailinglijst zit. De aanleiding is een recente discussie (zie [1]) over de juiste RD-parameters. Op donderdag 20 oktober a.s. organiseert OSGeo.nl het mini-seminar "RD en Open Source Software". Het doel is tweeledig: allereerst om de bezoeker kennis bij te brengen over coördinatenstelsels in het algemeen en het Rijksdriehoeksstelsel in het bijzonder. Het tweede doel is om coördinatenstelsels op een juiste manier toe te passen binnen software, waarbij de focus natuurlijk ligt op open source software. Het voorlopige programma is als volgt: * vanaf 16:00 uur: verzamelen / koffie * 16:30: start * 16:30 - 18:00: 1e deel * Erik Meerburg, GeoAcademie: introductie coördinatenstelsels en -transformaties * Jan Hartmann, Universiteit van Amsterdam / Thomas Vermaut, Fryske Akademy georeferentie historische kaarten (incl. triangulaties 1810 en 1930, alsmede transformatie naar WGS84) * Lennard Huisman, Kadaster: relatie RD, ETRS89 en WGS84, moeilijkheden, overstap naar ETRS89 * 18:00 - 19:00: pauze * 19:00 - 20:00: 2e deel * Edward Mac Gillavry, Webmapper: gebruik Proj.4 met OSGeo-software * Discussie * 20:00: afsluiting Het mini-seminar zal worden gehouden in de bovenzaal van Café Dudok, Larenseweg 1A te Hilversum (zie [2]). Tijdens de pauze is het mogelijk om gebruik te maken van een warme maaltijd. De kosten hiervan bedragen €10,- (dagmenu). Geef bij je aanmelding aan of je hiervan gebruik maakt of niet. Geef s.v.p. ook aan of je gebruik wilt maken van een vegetarische maaltijd. Aanmelden kan door je op te geven op MeetUp (zie [3]) of door een mail te sturen naar Frank Steggink. Laat in je aanmelding weten of je mee wilt eten of niet. Geef jezelf uiterlijk zo. 16 oktober op als je mee wilt eten. Wie mee wil eten wordt verzocht gepast geld mee te nemen of €10,- over te maken op rekening NL72 INGB 0006276370 t.n.v. Stichting OSGEO.nl o.v.v. "RD-eten". Mocht iemand ervaring hebben met het opnemen van presentaties en gemakkelijk over de juiste apparatuur kan beschikken, laat het ons s.v.p. weten. Mede namens het OSGeo.nl-bestuur, Frank Steggink [1] http://lists.osgeo.org/pipermail/dutch/2016-August/001465.html [2] http://www.cafedudok.com/ [3] https://www.meetup.com/OSGeoNL/events/234546607/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Luchtfoto's 2014 CycloMedia
Beste lijstgenoten, Vanochtend heb ik een e-mail gekregen van Cyclomedia met de URL van de endpoint + inloggegevens. Je kunt de WMS op de normale manier toevoegen. Wanneer je de lagen opvraagt, krijg je eerst een popup waar je de inloggegevens moet invullen. Kies vervolgens de laag NL_aerial_2014_50cm, wijzig eventueel de naam voor gebruik in JOSM en sla de laag op. De WMS ondersteunt geen EPSG:3857 (World Mercator), maar wel EPSG:4326 (WGS84). Op zich is dat niet erg, want er zijn geen verschilen die door rotatie ontstaan tussen WM en WGS84. Op kleine schaal (landelijk niveau) zul je wel verschil zien, maar op het schaalniveau waarop we de luchtfoto's gebruiken (dus ingezoomd op buurtniveau) niet. Een eerste indruk is dat deze laag goed ligt. Ik had ook niet anders verwacht, tenzij e.e.a. verschoven ligt vanwege offset-instellingen. De BAG-panden in Papendorp (blokkendozen) liggen perfect, maar bijv. bij mijn huis elders in Utrecht lijkt op het eerste gezicht een kleine afwijking te zijn. Bij nadere inspectie blijkt dit door de parallax te komen, dus het verschijnsel waarbij gebouwen gaan overhellen. De kwaliteit van de luchtfoto's vind ik tegenvallen. Ik had er meer van verwacht. 50cm is dus toch erg weinig. Niet genoeg voor het tekenen van features als je een hele hoge kwaliteit nastreeft (bijv. BGT-niveau), maar nog wel bruikbaar voor het alignen van wegen, e.d. Ook is de schaduw hinderlijk, terwijl het contrast van de lichte delen matig is. Misschien is de kwaliteit beter bij gebruik van het RD stelsel in JOSM. De gebruikte JOSM-versie is 9329, dus de laatste stabiele release (met RD-ondersteuning). Groeten, Frank On 10-1-2016 21:43, Frank Steggink wrote: Ik ben me nu aan het registreren. Ik vind wel dat er erg veel gegevens ingevuld moeten worden, bijv. geboortedatum. Ik mis dan ook een privacy-statement. (De link op de site gaat over de 360 graden-foto's.) Groeten, Frank On 10-1-2016 21:40, Frank Steggink wrote: Maarten, Zoals ik artikel 1.3.4 interpreteer van de ToU denk ik dat het niet is toegestaan om deze luchtfoto's tezamen met OSM te visualiseren. Het enige wat is toegestaan, is om ze te gebruiken voor het bijwerken van OSM. Je mag niet de key die je ontvangen zou moeten hebben (of gaat ontvangen) delen. De meest gedetailleerde luchtfoto's van Bing hebbne in het algemeen dezelfde resolutie. In ieder geval is de kwaliteit van de Bing-luchtfoto's vaak niet denderend, omdat ze voor een deel ook via een satelliet genoemn zijn. Verder zijn de Bing-foto's al een jaar of 5 à 6 oud. Er is hier gekozen voor de 2014-foto's, omdat dat ten tijde van de bespreking de meest recente dataset was. (De 2015 foto's werden nog verwerkt.) Of en wanneer de 2015-foto's beschikbaar worden gesteld, moet nog worden bekeken. Dat hangt ervan af hoe het gebruik van deze foto's wordt ervaren. Cyclomedia gebruikt OSM zelf ook, dus ze hebben zelf ook belang bij deze samenwerkeign. @Johan/Gert-Jan: waarom is er gekozen voor een engelstalige ToU? Groeten, Frank On 10-1-2016 20:49, Maarten Deen wrote: On 2016-01-10 20:38, Johan C wrote: We zijn erg verheugd om aan te kondigen dat CycloMedia via WMS luchtfoto's 2014 in een resolutie van 50 cm. ter beschikking stelt aan OpenStreetMap. Om toegang te krijgen tot de luchtfoto's moet je een licentie aangaan met CycloMedia. Dat kun je hier doen: http://www.cyclomedia.com/nl/openstreetmap/ Dat is goed nieuws. Ik heb wel wat vraagjes: Hoe verhoudt 50cm resolutie zich tot de meest gedetailleerde luchtfoto's van Bing? Ik heb geen idee wat daar de resolutie van is. Wat betekent precies de bewoording "I shall not integrate and/or visualize parts of the AerialNL50cm imagery in the OSM". Betekent dat soms dat ze ook niet getoond kunnen worden in JOSM? Als dat wel kan, kunnen de foto's dan als WMS layer in JOSM geladen worden en hoe? 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 ___ 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] Luchtfoto's 2014 CycloMedia
Ik ben me nu aan het registreren. Ik vind wel dat er erg veel gegevens ingevuld moeten worden, bijv. geboortedatum. Ik mis dan ook een privacy-statement. (De link op de site gaat over de 360 graden-foto's.) Groeten, Frank On 10-1-2016 21:40, Frank Steggink wrote: Maarten, Zoals ik artikel 1.3.4 interpreteer van de ToU denk ik dat het niet is toegestaan om deze luchtfoto's tezamen met OSM te visualiseren. Het enige wat is toegestaan, is om ze te gebruiken voor het bijwerken van OSM. Je mag niet de key die je ontvangen zou moeten hebben (of gaat ontvangen) delen. De meest gedetailleerde luchtfoto's van Bing hebbne in het algemeen dezelfde resolutie. In ieder geval is de kwaliteit van de Bing-luchtfoto's vaak niet denderend, omdat ze voor een deel ook via een satelliet genoemn zijn. Verder zijn de Bing-foto's al een jaar of 5 à 6 oud. Er is hier gekozen voor de 2014-foto's, omdat dat ten tijde van de bespreking de meest recente dataset was. (De 2015 foto's werden nog verwerkt.) Of en wanneer de 2015-foto's beschikbaar worden gesteld, moet nog worden bekeken. Dat hangt ervan af hoe het gebruik van deze foto's wordt ervaren. Cyclomedia gebruikt OSM zelf ook, dus ze hebben zelf ook belang bij deze samenwerkeign. @Johan/Gert-Jan: waarom is er gekozen voor een engelstalige ToU? Groeten, Frank On 10-1-2016 20:49, Maarten Deen wrote: On 2016-01-10 20:38, Johan C wrote: We zijn erg verheugd om aan te kondigen dat CycloMedia via WMS luchtfoto's 2014 in een resolutie van 50 cm. ter beschikking stelt aan OpenStreetMap. Om toegang te krijgen tot de luchtfoto's moet je een licentie aangaan met CycloMedia. Dat kun je hier doen: http://www.cyclomedia.com/nl/openstreetmap/ Dat is goed nieuws. Ik heb wel wat vraagjes: Hoe verhoudt 50cm resolutie zich tot de meest gedetailleerde luchtfoto's van Bing? Ik heb geen idee wat daar de resolutie van is. Wat betekent precies de bewoording "I shall not integrate and/or visualize parts of the AerialNL50cm imagery in the OSM". Betekent dat soms dat ze ook niet getoond kunnen worden in JOSM? Als dat wel kan, kunnen de foto's dan als WMS layer in JOSM geladen worden en hoe? 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 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Luchtfoto's 2014 CycloMedia
Maarten, Zoals ik artikel 1.3.4 interpreteer van de ToU denk ik dat het niet is toegestaan om deze luchtfoto's tezamen met OSM te visualiseren. Het enige wat is toegestaan, is om ze te gebruiken voor het bijwerken van OSM. Je mag niet de key die je ontvangen zou moeten hebben (of gaat ontvangen) delen. De meest gedetailleerde luchtfoto's van Bing hebbne in het algemeen dezelfde resolutie. In ieder geval is de kwaliteit van de Bing-luchtfoto's vaak niet denderend, omdat ze voor een deel ook via een satelliet genoemn zijn. Verder zijn de Bing-foto's al een jaar of 5 à 6 oud. Er is hier gekozen voor de 2014-foto's, omdat dat ten tijde van de bespreking de meest recente dataset was. (De 2015 foto's werden nog verwerkt.) Of en wanneer de 2015-foto's beschikbaar worden gesteld, moet nog worden bekeken. Dat hangt ervan af hoe het gebruik van deze foto's wordt ervaren. Cyclomedia gebruikt OSM zelf ook, dus ze hebben zelf ook belang bij deze samenwerkeign. @Johan/Gert-Jan: waarom is er gekozen voor een engelstalige ToU? Groeten, Frank On 10-1-2016 20:49, Maarten Deen wrote: On 2016-01-10 20:38, Johan C wrote: We zijn erg verheugd om aan te kondigen dat CycloMedia via WMS luchtfoto's 2014 in een resolutie van 50 cm. ter beschikking stelt aan OpenStreetMap. Om toegang te krijgen tot de luchtfoto's moet je een licentie aangaan met CycloMedia. Dat kun je hier doen: http://www.cyclomedia.com/nl/openstreetmap/ Dat is goed nieuws. Ik heb wel wat vraagjes: Hoe verhoudt 50cm resolutie zich tot de meest gedetailleerde luchtfoto's van Bing? Ik heb geen idee wat daar de resolutie van is. Wat betekent precies de bewoording "I shall not integrate and/or visualize parts of the AerialNL50cm imagery in the OSM". Betekent dat soms dat ze ook niet getoond kunnen worden in JOSM? Als dat wel kan, kunnen de foto's dan als WMS layer in JOSM geladen worden en hoe? 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] Nieuwjaarsborrel zo 10 jan 2016, Dudok Hilversum
Hoi, DIt is de huidige stand van zaken m.b.t. de presentaties: * Jan-Willem van Aalst: OpenTopo en BGT --> met name interessant voor de BGT-geïnteresseerden; * Johan de Ruiter en Gert-Jan van der Weijden: laatste stand van zaken Nederlandse luchtfotos; * Matthijs Melissen: laatste standv an zaken OpenStreetMap carto; * Just van den Broecke: terugblik OSGeo.nl over 2015 en vooruitblik over 2016. Aanmelden kan nog steeds, bij voorkeur via de link die Just heeft gemeld. Je kunt je ook bij Just melden als je zelf nog een praatje wilt houden. Groeten, Frank On 30-12-2015 11:09, Just van den Broecke wrote: Beste Mensen, Voor het vijfde achtereenvolgende jaar (lustrum) de traditionele OSGeo.nl+OSM-NL Nieuwjaarsborrel voor iedereen die open source geo-software en OpenStreetmap een warm hart toedraagt. Ook dit jaar weer in bovenzaal Cafe Dudok, Hilversum (t/o station NS), op zondag 10 jan 2016, vanaf 15:00. Er is ruimte voor "talks". Jan-Willem van Aalst zal bijv vertellen over de gloednieuwe BGT-visualisatie voor de geplande OpenTopo 3200pix/km. Opgeven, ook voor "talks", via OSGeo.nl Meetup: http://www.meetup.com/OSGeoNL/events/227097392 Hartelijke groet, --Just PS voor wie het gemist had, het verslag van NJ-Borrel 2015: http://osgeo.nl/2015/01/nieuwjaarsborrel-2015-de-presentaties ___ 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
[OSM-talk-nl] Samenwerking OSM en Rijkswaterstaat: de follow-up
Hoi, Zoals de meesten weten, was er op 19 september jl. een bijeenkomst bij Rijkswaterstaat in Utrecht met als doel om kennis te maken met de OSM community en om te kijken of wij (OSM en RWS) op een aantal vlakken nader kunnen samenwerken. Dit omdat er, ondanks de verschillen, ook gezamenlijke doelen zijn, nl. het beschikbaar stellen van open geodata. Naast Rijkswaterstaat waren er ook mensen van andere overheidsorganisaties aanwezig, zoals het Ministerie van Infrastructuur en Milieu en het Kadaster. Van deze bijeenkomst is een artikel beschikbaar: https://bgtweb.pleio.nl/blog/view/34894162/de-bgt-en-openstreetmap-samenwerkingskansen-in-beeld Uit deze bijeenkomst zijn een aantal ideeën voortgekomen om de mogelijke samenwerking nader uit te werken. Bij ieder initiatief zijn twee contactpersonen, namelijk één vanuit de overheid en één vanuit de community. Natuurlijk is iedereen van harte uitgenodigd om hieraan bij te dragen. Hier volgt een overzicht met korte toelichting van de initiatieven, tezamen met de namen en contactgegevens van de contactpersonen. Als je een bijdrage wilt leveren, kun je het beste contact zoeken met de contactpersonen. * OSM.NL voor dummies Contact OSM: Gert-Jan van der Weijden (gee...@dds.nl) Contact RWS: Ed Ooms (ed.o...@ndw.nu) Hiervan heb ik geen beschrijving gekregen, maar ik denk dat de titel wel voor zichzelf spreekt. * Echte kansen / meerwaarde van OSM voor RWS uitwerken Contact OSM: Henk Hoff (toffeh...@gmail.com) Contact RWS: Nelette Verbruggen (nelette.verbrug...@rws.nl) Doel: In deze groep willen we één echte kans voor Rijkswaterstaat qua samenwerking met Open Street Map uitwerken: iets waarin duidelijk en relatief snel meerwaarde te zien is van gebruik van de OSM-data voor RWS. Het snel laten zien van een concreet resultaat zal namelijk het enthousiasme bij RWS voor samenwerking verder aanwakkeren. Daarbij denken we nu aan de relatie tussen OSM en het nationaal wegenbestand (NWB), wat kan leiden tot efficiënter werken en een betere kwaliteit van beide bronnen. Status: Met het groepje 'echte kans/meerwaarde van OSM voor RWS uitwerken' hebben we de afgelopen weken via de mail al contact gehad. We proberen binnenkort bij elkaar te komen. Dat loopt dus! * Ontsluiting Basisregistratie Grootschalige Topografie (BGT) binnen OSM en v.v. Contact OSM: Frank Steggink (fr...@steggink.it) Contact RWS: Jaap-Willem Sjoukema (Min I) (jaapwillem.sjouk...@minienm.nl) Doel: Het doel van het BGT-initiatief is om te onderzoeken wat de mogelijkheden zijn om de Basisregistratie Grootschalige Topografie (BGT) binnen OSM te gebruiken en om te verkennen op welke manieren OSM gebruikt kan worden voor verrijking van de BGT. Bij gebruik van de BGT binnen OSM moet er verder worden gedacht dan het klakkeloos importeren van de BGT. Er zijn waarschijnlijk betere manieren te vinden om informatie uit de BGT te gebruiken. Er moet o.a. aandacht worden besteed aan een mapping tussen de gebruikte codering van de BGT en het OSM tagging-schema. Dit onderwerp leent zich bij uitstek voor het vormen van subgroepen die de uitwisseling van een specifieke set features nader onderzoeken. Status: Jaap-Willem en ik hebben beslotem om de discussie hierover op het OSM forum te bespreken: http://forum.openstreetmap.org/viewtopic.php?id=52338 Verder houdt Jaap-Willem Sjoukema zich bij het Ministerie van Infrastructuur en Milieu bezig met de ontwikkeling van een terugmeldsysteem voor de BGT, maar dat is niet specifiek op OSM gericht. * Subonderdeel BGT: kunstwerken in OSM Contact OSM kunstwerken: Nick Hoogerbrug (st.nikl...@live.nl) Contact RWS kunstwerken: Rob van der Schoot (rob.vander.sch...@rws.nl) Aangezien de BGT ook kunstwerken bevat, is besloten om dit als een subonderdeel van de BGT op te pakken. Eventueel worden andere bronnen, zoals het DTB van RWS, hiervoor gebruikt (eigen invulling). * Nationale bewegwijzering en OSM Contact OSM: Marc Zoutendijk (ma...@xs4all.nl) Contact RWS: Eric van der Ster (eric.vander.s...@rws.nl) Doel: in de nationale bewegwijzeringsapplicatie wordt noch OSM, noch RWS data gebruikt. Lijkt efficiënter en goedkoper te kunnen. Doel: open data als basis gebruiken in nationale bewegwijzeringsapplicatie. Waarom? Alle wegbeheerders gebruiken de applicatie, kijk naar de kracht van een eventuele terugmeldfunctie naar OSM en RWS! Status: voorstel heb ik (Eric vd Ster) neergelegd bij de directeur van de Nationale Bewegwijzeringsdienst * Luchtfoto's vrij beschikbaar krijgen Contact OSM: Gert-Jan van der Weijden (gee...@dds.nl) Contact RWS: Ed Vaessen (ed.vaes...@rws.nl) Doel: de landsdekkende luchtfoto’s worden jaarlijks door gezamenlijke overheden (behalve de gemeenten) aangeschaft. Er is een variant met 10cm resolutie die is opgenomen in het bladloze seizoen (voorjaar, tot 23 april) en een met 25cm resolutie, opgenomen van 15 april t/m 15 juli. Alleen de laatste variant, gedownsampled naar 50cm, is als open
Re: [OSM-talk-nl] [Dutch] AmsGeoDrinks - Zeppos do 27 aug
Voor degenen die er niet bij waren: we hebben op een passende wijze uitgeleide gedaan van Steven! Hier de bewijzen: * http://www.meetup.com/AmsGeoDrinks/photos/26367142/441356154/?a=pu3.2_l * http://www.meetup.com/AmsGeoDrinks/photos/26367142/441356179/?a=pu3.2_l Voor wie de tekst op de tweede foto beter wil lezen: http://lists.osgeo.org/pipermail/dutch/2007-October/00.html Groeten, Frank On 25-8-2015 15:11, Just van den Broecke wrote: Op 27/8 weer een Amsterdam Geo Drinks ter ere van vertrek ons voormalig OSGeo.nl bestuurslid Steven naar USA DC, opgeven op http://www.meetup.com/AmsGeoDrinks/events/224785253 Hartelijke groet, Just ___ Dutch mailing list du...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/dutch ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Uitnodiging voor brainstormsessie samenwerking OSM-RWS.
Beste Eric, Met je goedvinden stuur ik je oproep tevens door naar de OSGeo.nl mailinglijst. Daar zitten ook veel mensen die OSM kennen en een goede inbreng kunnen leveren, maar die misschien niet OSM talk-nl in de gaten houden. Verder zou ik speciale aandacht willen vragen voor mensen die betrokken zijn bij of bijdragen aan OpenSeaMap. Weet iemand of hier ook Nederlanders bij betrokken zijn? Dit i.v.m. de schat aan gegevens die Rijkswaterstaat heeft over water. Groeten, Frank Steggink On 9-6-2015 11:36, Ster, Eric van der (CIV) wrote: Beste OSM-ers Om te beginnen zal ik mij even voorstellen: Eric van der Ster. Ik werk bij de Centrale Informatievoorziening van Rijkswaterstaat. Op de bijeenkomst op het Geofort is het idee ontstaan om een sessie te organiseren om de mogelijkheden van samenwerking tussen OSM en RWS te verkennen. Rijkswaterstaat is beheerder van het hoofdwegennet, hoofdvaarwegennet en hoofdwatersysteem, de bijbehorende data en een aantal nationale basisbestanden. Al langere tijd stelt Rijkswaterstaat data open voor hergebruik. Per 1-1-2015 is daar een grote impuls aangegeven door een groot deel van de Rijkswaterstaat data open te stellen voor hergebruik. Dat hergebruik is voor RWS belangrijk: het helpt RWS de kwaliteit van de data te verbeteren én het hergebruik versterkt de beleidsdoelstellingen op het gebied van leefomgeving/milieu, bereikbaarheid en veiligheid. De brainstormsessie is op 19 september 2015 van 11:00-17:00. Locatie is nog niet definitief (vermoedelijk Utrecht). Op basis van wat heen -en weer mailen is het volgende programma ontstaan: 1.thema Community Organisatie Doel: Hoe kunnen RWS en OSM Nederland gezamenlijk een omvangrijke en actieve community creëren, waar zowel Rijkswaterstaat als OSM van profiteren om relevante onderliggende databases zo betrouwbaar mogelijk te houden tegen minimale kosten? 2.thema Open data, hergebruik en feedback” Doel: Op welke manier creëren we een eco-systeem van data, waarbij zowel OSM als Rijkswaterstaat profiteren van de kwaliteit en actualiteit van de data van elkaar? 3.thema “Dataproeverij” Doel: Aan de slag met de data in de praktijk. Aan de hand van concrete vraagstukken gezamenlijk werken aan oplossingen. Suggesties en aanmeldingen zijn uiteraard welkom. (bij eric.vander.s...@rws.nl met naam en bij voorkeur met interessegebied ). Met vriendelijke groet, Eric van der Ster Coordinerend/Specialistisch Adviseur . Strategie en Beleid Rijkswaterstaat Centrale Informatievoorziening Derde Werelddreef 1 | 2622 HA Delft Postbus 5023 | 2600 GA Delft . T: +31-15-275 7345 M: +31-6-51435420 ___ 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] irc like chatroom
Dag Jo, Op http://irc.openstreetmap.org/ is er een channel #osm-nl. Ik heb geen idee of daar nog wel eens mensen opzitten. Vroeger kwam ik er wel eens, maar de laatste jaren ben ik er niet meer geweest. Groeten, Frank On 13-1-2015 20:48, Jo wrote: Hallo, Wat ik een beetje mis, is zoiets als irc, waar je kon binnenvallen wanneer het je uitkomt. Hier is een experimentje dat dat hiaat wellicht kan opvullen: https://meet.jit.si/osmbe 't Werkt wel enkel in Chrome/Chromium. Groeten, Jo ___ 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] [Dutch] OSM borrel + AAN-data
Hoi Paul, Wat de perceelsgrenzen betreft: deze zitten in OSM, voor zover ze in 3dShapes aanwezig waren en niet door mensen zijn samengevoegd. Voor akkerland heeft OSM enige tijd een wijziging in de stylesheet doorgevoerd om de grenzen te accentueren, maar voor grasland is dit niet gedaan. Dit zie je ook in je screenshot. V.w.b. de actualiteit zou het zinvol zijn om de data aan OSM toe te voegen, mits de data goed te mappen is naar de OSM tags. Maar wat betreft de hoeveelheid werk zou ik het sterk afraden. Voor specifieke toepassingen kun je veel beter de AAN-data rechtstreeks gebruiken, zoals Jan-Willem aangeeft. Een andere factor wat het updaten lastig maakt is dat de landgebruik-vlakken allemaal aan elkaar vastzitten, waardoor het updaten veel meer inspanning kost dan het toevoegen of verwijderen van losse gebouwen. De enige use case waar ik AAN-data wel geschikt voor zou vinden is in gebieden waar OSM sterk outdated is, bijv. in de buurt van stadsuitbreidingen en/of nieuwe (rijks)wegen. Landgebruik is lastig te editen en de Bing luchtfoto's zijn vaak niet actueel, waardoor de landuse niet op een fatsoenlijke manier bijgewerkt kan worden. Maar zelfs dan zit je nog met zaken zoals bermen, omdat die geen agrarische bestemming hebben. Het is hoe dan ook uitkijken. Groeten, Frank Steggink p.s. Cross-post naar OSM talk-nl, waar deze discussie eigenlijk thuis hoort. On 5-1-2015 15:11, Paul Meems wrote: Goedemiddag, Ik kan jammer genoeg niet bij de komende OpenStreetMap NL nieuwsjaarborrel anwezig zijn. Maar ik heb wel een vraag/opmerking over OSM. We gebruiken OSM data in onze webapplicatie en daar over heen leggen we AAN-data (Agrarisch Areaal Nederland). Deze AAN-data is vrij verkrijgbaar bij PDOK en wordt elk jaar opnieuw aangeleverd nadat de boeren hun wijzigingen hebben doorgegeven (in april). Is het zinvol/handig/leuk/nuttig om die data toe te voegen aan de OSM data? Je hebt dan de perceelsgrenzen en wat er op verbouwd wordt. Het gaat misschien te ver om elk gewas dan een eigen kleur te geven, maar je kunt wel een onderscheid maken tussen akkerbouw en grasland. Visueel wordt het in ieder geval 'mooier'. ik heb twee plaatjes toegevoegd. Eentje van OSM alleen en eentje met de AAN-data als extra laag (in magenta). Zonder AAN heb je grote groene vlakken. Met AAN kun je de perceelsgrenzen zien. Inline afbeelding 1 Inline afbeelding 3 Ik ben benieuwd wat de OSM-editors hiervan vinden. Ik ben zelf enkel een gebruiker ;) Met vriendelijke groet, Paul Meems *Paul Meems *Senior GIS consultant 06-53989481 TopX Geo-ICT http://www.topx-geo-ict.nl http://topx-group.nl/topx-geo-ictWij bieden ondersteuning voor MapWindow GIS http://www.mapwindow.org/ De Engelse presentaties van de MapWindow Open Source GIS 2014 conferentie in Debrecen, Hongarije. http://www.slideshare.net/MapWindow/presentations ___ Dutch mailing list du...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/dutch ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Forum en mailinglijst: 2 kapiteins op hetzelfde schip?
Quoting Marc Zoutendijk marczoutend...@mac.com: Tevens wijs ik erop dat niet ik pleit voor opheffing, maar de OP van dit topic. Ik ondersteun hem wel. Gert-Jan kennende is dit zijn stijl om een discussie te starten. Ik kan me de twinkeling in zijn ogen toen hij zijn mail schreef goed voorstellen ;) Gelukkig is het niet aan hem alleen om een keus te moeten maken tussen forum en mailinglijst. Gezien de reacties denk ik dat we deze keus ook helemaal niet moeten maken, omdat de een bij het forum zweert en de ander bij de mailinglist. Aangezien er techonologie bestaat om beide te koppelen, moeten we dit vooral gaan inzetten om beide werelden (want dat zijn het wel) te combineren! Dat is ook de achterliggende vraag van Gert-Jan, waarin ik hem juist wel ondersteun. Ik heb de discussie rond het OSMF-forum niet helemaal gevolgd, maar volgens mij was er iemand die dit al heeft voorgesteld. Voor mensen zonder account op het forum schijnt automatisch een of ander dummy-account aangemaakt te worden. Groeten, Frank Steggink ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Forum en mailinglijst: 2 kapiteins op hetzelfde schip?
Ik kreeg wel een bericht binnen dat Marc heeft geantwoord in het topic: marczoutendijk has replied to the topic 'Test' to which you are subscribed. There may be more new replies, but this is the only notification you will receive until you visit the board again. The post is located at http://forum.openstreetmap.org/viewtopic.php?pid=467158#p467158 The message reads as follows: --- Ik heb het in ieder geval gelezen! Welkom! --- You can unsubscribe by going to http://forum.openstreetmap.org/misc.php?action=unsubscribetid=28262 -- OpenStreetMap Forum Mailer (Do not reply to this message) Ik kan het bericht lezen, maar ben niet gelukkig met het formaat. De forum mailer heeft blijkbaar veel tekst nodig om het antwoord te versturen. Ook kan ik niet hierop antwoorden. Ook zie ik niet eventuele latere berichten, volgens de tekst There may be more new replies, but this is the only notification you will receive until you visit the board again. Conclusie: dit werkt niet. Op RSS feeds kun je ook niet antwoorden. Groeten, Frank Steggink Quoting stegg...@steggink.org: Quoting Marc Zoutendijk marczoutend...@mac.com: Tevens wijs ik erop dat niet ik pleit voor opheffing, maar de OP van dit topic. Ik ondersteun hem wel. Gert-Jan kennende is dit zijn stijl om een discussie te starten. Ik kan me de twinkeling in zijn ogen toen hij zijn mail schreef goed voorstellen ;) Gelukkig is het niet aan hem alleen om een keus te moeten maken tussen forum en mailinglijst. Gezien de reacties denk ik dat we deze keus ook helemaal niet moeten maken, omdat de een bij het forum zweert en de ander bij de mailinglist. Aangezien er techonologie bestaat om beide te koppelen, moeten we dit vooral gaan inzetten om beide werelden (want dat zijn het wel) te combineren! Dat is ook de achterliggende vraag van Gert-Jan, waarin ik hem juist wel ondersteun. Ik heb de discussie rond het OSMF-forum niet helemaal gevolgd, maar volgens mij was er iemand die dit al heeft voorgesteld. Voor mensen zonder account op het forum schijnt automatisch een of ander dummy-account aangemaakt te worden. Groeten, Frank Steggink ___ 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] Forum en mailinglijst: 2 kapiteins op hetzelfde schip?
Nog een update: aangezien ik ook op het forum ben gesubscribed, zou ik verwachten dat ik ook bericht zou krijgen van antwoorden op andere topics. Deze heb ik niet gehad, terwijl er wel nieuwe antwoorden zijn (bijv. op Huisnummers voor de konijntjes). Groeten, Frank Steggink Quoting stegg...@steggink.org: Ik kreeg wel een bericht binnen dat Marc heeft geantwoord in het topic: marczoutendijk has replied to the topic 'Test' to which you are subscribed. There may be more new replies, but this is the only notification you will receive until you visit the board again. The post is located at http://forum.openstreetmap.org/viewtopic.php?pid=467158#p467158 The message reads as follows: --- Ik heb het in ieder geval gelezen! Welkom! --- You can unsubscribe by going to http://forum.openstreetmap.org/misc.php?action=unsubscribetid=28262 -- OpenStreetMap Forum Mailer (Do not reply to this message) Ik kan het bericht lezen, maar ben niet gelukkig met het formaat. De forum mailer heeft blijkbaar veel tekst nodig om het antwoord te versturen. Ook kan ik niet hierop antwoorden. Ook zie ik niet eventuele latere berichten, volgens de tekst There may be more new replies, but this is the only notification you will receive until you visit the board again. Conclusie: dit werkt niet. Op RSS feeds kun je ook niet antwoorden. Groeten, Frank Steggink Quoting stegg...@steggink.org: Quoting Marc Zoutendijk marczoutend...@mac.com: Tevens wijs ik erop dat niet ik pleit voor opheffing, maar de OP van dit topic. Ik ondersteun hem wel. Gert-Jan kennende is dit zijn stijl om een discussie te starten. Ik kan me de twinkeling in zijn ogen toen hij zijn mail schreef goed voorstellen ;) Gelukkig is het niet aan hem alleen om een keus te moeten maken tussen forum en mailinglijst. Gezien de reacties denk ik dat we deze keus ook helemaal niet moeten maken, omdat de een bij het forum zweert en de ander bij de mailinglist. Aangezien er techonologie bestaat om beide te koppelen, moeten we dit vooral gaan inzetten om beide werelden (want dat zijn het wel) te combineren! Dat is ook de achterliggende vraag van Gert-Jan, waarin ik hem juist wel ondersteun. Ik heb de discussie rond het OSMF-forum niet helemaal gevolgd, maar volgens mij was er iemand die dit al heeft voorgesteld. Voor mensen zonder account op het forum schijnt automatisch een of ander dummy-account aangemaakt te worden. Groeten, Frank Steggink ___ 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] Forum en mailinglijst: 2 kapiteins op hetzelfde schip?
Quoting Maarten Deen md...@xs4all.nl: On 2014-11-28 12:02, Paul Smits wrote: Ik zie het vrij simpel: het forum is voor de discussie met actieve mappers, de mailinglijst voor vragen van mensen met forumvrees en om alle mappers te bereiken voor belangrijke zaken. Zoals belangrijke aankondigingen die voor alle mappers van belang zijn, over imports bijvoorbeeld, of uitnodigingen voor mapping parties. Of wanneer er iets goed stuk is, en het niet helemaal duidelijk is wie er schuld aan heeft ;) Dat vind ik een stigmatisering waarmee je jezelf eigenlijk al buitenspel zet. Ik ben ook een actieve mapper. Ik heb geen forumvrees, ik volg genoeg forums. Ik heb verder nog geen steekhoudende verklaring gezien waarom er een forum gemaakt moest worden als er al een functionerende mailinglijst bestaat. Omdat sommige mensen fora gemakkelijker vinden. Ieder zijn ding. Het forum bestond zeker al in 2007. Ik vind het wel bijzonder dat je hier pas 7, bijna 8 jaar later achter komt :) Het verwondert me alleen zeer dat er blijkbaar twee communities kunnen ontstaan: de forumcommunity en de mailinglijstcommunity die blijkbaar gescheiden zijn en waar mensen weinig van elkaar afweten. Iig geldt dat voor mij. Blijkbaar heb ik nu mijn 3e post op het forum gemaakt terwijl ik gisteren nog totaal vergeten was dat het forum überhaupt bestond. Het verwondert mij niet. Blijkbaar is er niet zo veel overlap tussen het forum en de mailinglist v.w.b. de actieve leden. De mailinglijst is sowieso niet heel erg actief de laatste jaren. Blijkbaar wordt hij wel door aardig wat mensen gelezen, wat ik een goede zaak vind. Tevens is dit bewijs dat de mailinglist zeker NIET achterhaald is. Ik vind het wel jammer dat er twee communities zijn. Zo groot is Nederland ook niet, dus het zou beter zijn als we beide communities kunnen verenigen. Zeker als er technische mogelijkheden zijn. Natuurlijk moet het ene medium niet ten koste gaan van het andere medium! Gert-Jan, aangezien jij de knuppel in het hoenderhok hebt gegooid, is het tijd om hem er nu maar weer uit te halen? Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Forum en mailinglijst: 2 kapiteins op hetzelfde schip?
Geachte heer Zoutendijk, Die koppeling is wel nodig om nieuwe items te posten vanuit je e-mail client en om de discussies in het talk-nl archief te krijgen. Verder vind ik de manier waarop u degenen die de mailinglist prefereren bejegent niet prettig. Binnen een community als OSM vind ik het zelfs behoorlijk ongepast. Juist de kracht van OSM is dat er een behoorlijke mate van vrijheid is. De manier waarop u pleit om de mailinglist te sluiten, vind ik een inbreuk van mijn vrijheid, namelijk de vrijheid om het door mij gewenste medium te gebruiken. Hoogachtend, Frank Steggink Quoting Marc Zoutendijk marczoutend...@mac.com: Op 28 nov. 2014, om 07:59 heeft stegg...@steggink.org het volgende geschreven: Als een koppeling tussen de mailinglijst en forum mogelijk is, dan denk ik dat dit de beste optie is. Iedereen kan dan het medium gebruiken dat hij/zij het prettigst vindt. Die koppeling is niet nodig. Persoonlijk ben ik voorstander van de mailinglijst. Reden: gemak. Ik hoef alleen maar mijn mail te openen om te zien dat er nieuwe discussies zijn. Ze komen in een aparte mailfolder terecht. Bij het forum moet ik er uberhaupt eerst aan denken om het te bezoeken en als ik ergens op wil reageren moet ik ook nog eens inloggen. Want je kunt je op het forum abonneren zodat de berichten ook je mailbox bereiken. Je mist helemaal niets. Bovendien is mijn ervaring dat het forum aanmerkelijk beter bezocht is en meer onderwerpen en deelnemers kent dan de mailinglist. Dus als je het rustig wilt houden dan blijf je op de list. Maar ik zou zeggen: ga eens kijken op het forum en zie hoe het werkt. Het feit dat de meeste reacties hier aangeven dat ze bang zijn iets te missen geeft al aan dat ze de werkwijze van het forum niet kennen. Marc. ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Fwd: [Dutch] 13 dec. Missing Maps Mapathon in Antwerpen
Hoi, Deze aankondiging hoort natuurlijk ook op OSM talk-nl thuis. Verder schijnt er op 5 dec. tevens een mapathon in Middelburg te zijn. Willy, heb jij hier details over? Ik heb deze aankondiging nog nergens langs zien komen. Vandaag is op de Geobuzz ook een mapathon in het midden van het land aangekondigd. Deze zal plaatsvinden op za. 14 feb. op het Geofort bij Leerdam. Details volgen later. Groeten, Frank Steggink Original Message Subject:[Dutch] 13 dec. Missing Maps Mapathon in Antwerpen Date: Mon, 24 Nov 2014 20:19:25 +0100 From: Willy Bakker friesewoudlo...@gmail.com To: du...@lists.osgeo.org du...@lists.osgeo.org Beste leden van de mailinglijst, 13 december organiseert de Belgische OpenStreetMap community een Missing Maps Mapathon. Het Missing Maps project is een samenwerkingsverband tussen Artsen Zonder Grenzen, het Amerikaanse en Britse Rode Kruis en het Humanitarian OpenStreetMap Team (HOT). Kijk voor meer informatie over Missing Maps bijvoorbeeld hier http://www.missingmaps.org of hier http://www.radio1.be/programmas/vandaag/%E2%80%9Cmissing-maps%E2%80%9D-brengt-de-wereld-kaart. Het zou heel leuk zijn wanneer we met een groepje Nederlandse (aspirant) mappers afreizen naar Antwerpen. Niet alleen leerzaam en nuttig, maar ook gezellig! (We gaan dan 's avonds natuurlijk ook even het uitgaansleven in de stad in kaart brengen...) Wellicht doen we dan ook inspiratie op om een Missing Maps Mapathon in NL te organiseren. Hoe dan ook, wil je op 13 dec. meedoen met de mapathon, laat het me weten en geef je op via http://osm.be/nl/content/missing-maps-mapthon. Vriendelijke groet, Willy Bakker friesewoudloper N.B.: Ook al heb je nog nooit iets ingetekend in OpenStreetMap, je bent van harte welkom. Voor beginners is er een introductie, waarna ook zij aan de slag kunnen. ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Oxilion en Stichting OpenGeo gaan openstreetmap.nl upgraden
On 7-10-2014 0:56, Stefan de Konink wrote: On Monday, October 6, 2014 5:47:03 PM CEST, Stefan de Konink wrote: - De data mirror wordt geplaatst op een server met tenminste 2x 1TB aan SATA in RAID-1, een niet rundante 500GB SSD en 3x 73GB SAS schijven. Het systeem heeft zelf 128GB aan RAM. Korte update: een gulle gever heeft zich gemeld. Het wordt nu 5x 2TB. In RAID-6 levert dat 6TB aan slow storage op, genoeg om even vooruit te kunnen. Voor het betere BAG database werk is er nog een SSD. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl Goed werk Stefan! En een bedankje richting Oxilion is ook zeker op zijn plaats! Groeten, Frank Steggink ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Netherland mapping for Tourists / Adress nodes move to building etc
Hi Florian, The quality issues you mentioned about the imported data is due to the rules by which the government has collected this data. For example: the tiny forests from the 3dShapes import (not the AND import) also appear on the topographical maps. I've examined way 74390172 as an example. Have a look at this map sheet: http://geodata.nationaalgeoregister.nl/top25raster/extract/kaartbladen/TOP25raster_67A.zip?formaat=geotiff There is probably a rule at the Kadaster (the Cadastre, also our national mapping agency) saying that a patch like this should be interpreted as a forest, even though there are only 5 or 6 trees visible on the Bing imagery. Also the building you described as having been drawn by a 5 year old child: unfortunately buildings which have not been finished have not had the proper measurements taken by the local government. They will update the building after a while the building has been completed. This might take several months. It really depends on the processes within the municipality. That also explains why you might see quality differences between municipalities. Landuse = farm is not necessarily wrong. There is an entire wiki page devoted to this tag: http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dfarm. This import (3dShapes) was done several years ago, and it is possible that tagging best practices now describe that croplands should be tagged as landuse = farmland. Regarding the highway = unclassified tag from the AND import: this was before my time, but I believe it was caused by a lack of granularity of the highway types in the original data. Regarding the tags: in my opinion they can all be deleted. We're not going to receive any updates from them anyways. Regards, Frank On 5-10-2014 21:45, Florian Lohoff wrote: Hi Johan, On Sun, Oct 05, 2014 at 04:49:15PM +0200, Johan C wrote: Hi Florian I invite you to make comments on the OpenStreetMap forum ( http://forum.openstreetmap.org/viewforum.php?id=12) because there's more Dutch mappers active there. Awaiting your input there, I'll already do a short reply to you, Hmm i am not the kind of Forum user. I like my email program which helps me to get the threads together ;) or a couple of years i have been to Zeeland in Autumn and as always i have a little time to spend on mapping. Great, especially on POI's there's a lot of work left Not only pois. Most of the map around here hasnt been touched since the original AND import. Still a lot of broken highway=pedestrian etc. What i found: - A lot and i really a LOT of landuse topology errors. Layered over each other without any method i can find. Mixing of landuse and highway nodes e.g.. Sometimes single trees as a landuse=forest in the middle of the city. - Use of landuse=farm where landuse=farmland would be right. - highway=pedestrian for highway=service or path/foot/bicycle type roads. - highway=unclassified everywhere - no residential in the citys. - Strange highway name changes - Sometimes not at the crossing but 10m after which can not be found on ground. - A lot of very strange oneways for which some i verified to be non existant. Are you planning to move the addresses on the appropriate building outlines? No. Since the address nodes are in the proximity of the entrance that would substantially lower the quality Okay - so i dont move nodes except where it makes sense to an entrance on the building outline. There's no special local preference, so the standard OSM practice applies. In the case of one building/one POI I add all information (including address info) to the building outline ánd I prefer to put the entrance node on the building outline. In the case of one building/multiple POI's I put all POI info in a node. I am just asking before breaking stuff the NL community has agreed to handle differently. What about strange buildings from the BAG import? I have a couple cases where the building outline does not at all match the building in a mapbox sat imagery. The BAG should contain the correct building outline, since this is Cadastral information, nowadays updated very often. But as any database, the BAG might incidentally have errors. Satellite imagery though is at risk of being well outdated. So in these cases it's possibly best to have groun truth info to determine the correct building outline. I have found buildings which have a start_date of 2014 and are not orthogonal and dont match the sat imagery. Yes - i'll have a look whether its a new construction but the data looks like a 5 year old drew something in EPSG:4326 Example: http://osm.org/go/0EmBaMKXz--?m= I also found a BAG imported underground parking which is rendered very prominent on the map. From looking at the data i have the feeling that a layer=-1 should at least be added but. I agree., all underground buildings should have had layer -x And in case of parking i am not shure its a wise decision to actually import it. Example:
[OSM-talk-nl] Vervoer SOTM-EU aanbod
Hoi, Over twee weken ga ik naar SOTM-EU in Karlsruhe. Ik ben van plan om met de auto te gaan en ik kan dus een aantal mensen meenemen (2, hooguit 3, maar dat wordt krap). Ik ga op do. 12 juni rond 09:00 uur weg uit Utrecht en ik kom ma. 16 juni weer terug. Ik ben in ieder geval van plan om bij Venlo de grens over te gaan en dan de A-61 te nemen. Afhankelijk van wie zich het eerst meldt, ga ik of over Den Bosch/Eindhoven of over Arnhem/Nijmegen. Stuur me een mail, zodat we kunnen afspreken waar/hoe laat ik je op kan halen. Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSGeo.nl + OSM-NL Nieuwjaarsborrel 12 januari
Hoi Just, Ik wil wel een praatje houden over mijn visualisatieprojectjes o.b.v. NLExtract en TileMill. Het zal vnl. een beetje demoën/showen worden. Groeten, Frank On 19-12-2013 15:22, Just van den Broecke wrote: Klinkt goed! We hebben nog geen echte invulling voor een programma. We gaan in ieder geval ook ruimte houden voor ter-plekke lightning praatjes, bijv. aankondiging project waar je mensen voor zoekt, een aktiviteit die je zou willen starten (geconverteerde BAG data hosting?), ik noem maar iets. Zang, dans en/of gitaar?, ook prima. Ik neem aan dat vertegenwoordigers van OSGeo.nl en OSM-NL/OSMF een verlichtend praatje gaan houden. Als er meer bekend is over BAGImport praatje (wie?) laat mij weten dan zet ik dat ook op de site/Meetup. Voor we het weten hebben we een mini-conferentie :-). groet, Just On 19-12-13 09:34, Johan C wrote: Er is een idee om een presentatie te geven over de BAGimport. Maar ik heb dat (vanwege andere verplichtingen eerder die middag) dan liever aan het begin tussen 3 en 4. Het is nl. interessant genoeg voor alle aanwezigen (denk ik) Gr. Johan Op woensdag 18 december 2013 schreef Just van den Broecke (j...@justobjects.nl mailto:j...@justobjects.nl): Beste Mensen, Op zondag 12 januari 2014 vanaf 15:00 geven OSGeo.nl en OpenStreetMap de alweer bijna traditionele Nieuwjaarsborrel. Dit jaar is de locatie Cafe Dudok (bovenzaal) in Hilversum. Tegenover Station NS en met goede parkeergelegenheid. Dit is je kans om iedereen weer te ontmoeten en plannen te maken voor het nieuwe jaar. Als je van plan bent te komen, laat weten via de Meetup: http://www.meetup.com/OSGeoNL/events/156113292 of mail mij direct. We hopen jullie daar te zien! Hartelijke groet, --Just, Gert-Jan, Barend, Steven, Henk en Floris PS de plek is een leuke bovenzaal http://www.cafedudokhilversum.nl/135260732 met beamer en Wifi. Laat mij weten of je voor 15:00 nog met een werkgroep (BAG?) o.i.d. bijeen wilt komen, dan reserveren we vanaf eerder tijdstip. ___ Talk-nl mailing list Talk-nl@openstreetmap.org mailto: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 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Mensen die voordracht over OSM geven?
Raymond, probeer anders het OSM forum: http://forum.openstreetmap.org/viewforum.php?id=12 Waarschijnlijk is dat nu wel erg kort dag. Frank On 11-11-2013 0:32, Raymond wrote: Helaas nog geen geïnteresseerden gevonden, sowieso lijkt deze mailinglijst een beetje dood. Dat laatste is wel jammer omdat openstreetmap best awesome is. On 6-11-2013 13:29, Henk Hoff wrote: Hoi Raymond, Zoals het er nu naar uitziet, zou ik wel kunnen. Echter, aangezien Delft voor mij wel een beetje aan de andere kant van het land is het misschien handiger (wanneer je meerdere gegadigden hebt) om voor iemand anders te kiezen :-) Laat maar even weten. Gr, Henk Hoff 2013/11/5 Raymond van Vugt ligfietsraym...@gmail.com mailto:ligfietsraym...@gmail.com Hoi,5/ voor het weekend van de piratenpartij zoek ik eigenlijk een ervaren OSM'er die duidelijk en vrijblijvend OSM zou willen presenteren op 15/16 november te Delft. Zelf ben ik hypergeïnteresseerd, anderen ook, maar verder als openfietsmap op de garmin installeren en een beetje editten in potlach kom ik niet echt. Interesse? dan houdt ik me aanbevolen Groet, Raymond van Vugt ___ Talk-nl mailing list Talk-nl@openstreetmap.org mailto: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 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Meetup met OSM BE over adressen imports
On 6-10-2013 12:30, Johan C wrote: Op zaterdag 16 november zal in het Belgische Hoogstraten een meeting plaatsvinden van de Nederlandse en Belgische OSM community met als doel het maken van afspraken over het importeren van alle adressen in Nederland en Vlaanderen uit openbare databronnen (BAG / CRAB). Onderdeel daarvan zijn 1) het opstellen van een address removal policy 2) een address import policy 3) een address maintenance policy en 4) afspraken over de uitvoering van de import. Dit is een ingewikkeld vraagstuk waarbij compromissen noodzakelijk zijn, met name als gevolg van de beperkt beschikbare tijd van OSM vrijwilligers. Om succesvol te zijn zal de meeting in de weken voor 16 november enige voorbereidingstijd vergen. Mocht je interesse hebben om deel te nemen aan de voorbereiding en de meeting, laat dat dan s.v.p. uiterlijk 12 oktober weten via osm...@gmail.com mailto:osm...@gmail.com. Dit mailadres kun je ook gebruiken indien je op 16 november niet aanwezig kunt zijn maar wel wilt deelnemen aan de voorbereiding. Cheers, Johan ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl Hoi Johan, Gaat dit ondermeer over de BAG-import meeting die Gert Jan Idema en Sebastic van plan zijn te organiseren? Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Talk-nl Digest, Vol 79, Issue 2
Dag Theo, De 1:5 kaart is een gegeneraliseerd product. Dat betekent dat er data moet worden weggelaten om een goed kaartbeeld te geven. De kartografische weergave is belangrijk bij generalisatie, maar dat gaat (zoals je ziet) wel ten koste van de nauwkeurigheid. Dit schaalniveau is dan ook meer bedoeld voor orientatie. De reden dat ik een gigapan hiervan heb gemaakt (en niet van de 1:25000 kaart) is dat afgelopen week deze nieuwe versie is vrijgegeven. Het bijzondere hieraan is dat de generalisatie (d.w.z. aanpassingen aan de kaarten om dingen weg te laten en/of te verschuiven) geheel automatisch is verlopen. Voor een landsdekkende serie is dat een unieke presentatie. Mocht iemand toch iets met de BRT-data in OSM willen doen, dan zou ik, naast er eerst heel goed over nadenken of je het echt moet willen, de TOP10NL vectordata gebruiken. De 1:5 kaart en de nog te releasen data is hiervoor veel minder geschikt. Ik had misschien beter moeten benadrukken dat de instemming van het Kadaster voor hergebruik van de BRT-data niet specifiek voor de 1:5 kaart bedoeld is. Groeten, Frank On 11-9-2013 12:30, Theo de Kraker wrote: Hallo Frank, Ik ben een complete leek bij openstreetmap maar wel geïnteresseerd. N.a.v. je mail op 7 september j.l. : Talk-nl Digest, Vol 79, Issue 2 reageer ik op het Gigapan Topraster. Daaarbij heb ik even gekeken naar mij woonplaats Almere, waarbij ik zover mogelijk ben ingezoomd. Wat mij betreft is die kaart maar zeer beperkt bruikbaar, n.l. alleen geschikt om in de gewenste wijk te komen. De straten in een wijk worden wel aangegeven, echter zo onnauwkeurig, dat je er niet mee kunt navigeren, omdat busbanen, fietspaden, etc. vaak hetzelfde worden aangegeven als gewone wegen. De huidige OS-map is beter! mvg, Theo de Kraker Op 7 september 2013 14:00 schreef talk-nl-requ...@openstreetmap.org mailto:talk-nl-requ...@openstreetmap.org: Send Talk-nl mailing list submissions to talk-nl@openstreetmap.org mailto:talk-nl@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk-nl or, via email, send a message with subject or body 'help' to talk-nl-requ...@openstreetmap.org mailto:talk-nl-requ...@openstreetmap.org You can reach the person managing the list at talk-nl-ow...@openstreetmap.org mailto:talk-nl-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-nl digest... Today's Topics: 1. Gebruik data Basisregistratie Topografie (Frank Steggink) -- Message: 1 Date: Fri, 06 Sep 2013 18:16:41 +0200 From: Frank Steggink stegg...@steggink.org mailto:stegg...@steggink.org To: OpenStreetMap NL discussion list talk-nl@openstreetmap.org mailto:talk-nl@openstreetmap.org Subject: [OSM-talk-nl] Gebruik data Basisregistratie Topografie Message-ID: 5229ffe9.7010...@steggink.org mailto:5229ffe9.7010...@steggink.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hoi, Bij mij en diverse anderen was de indruk aanwezig dat data van de Basisregistratie Topografie (BRT) in OSM niet toegestaan is, omdat de licentie (CC-BY-SA) incompatible zou zijn met ODbL. De licentie van alle BRT-producten (vector ?n raster) blijkt geruime tijd geleden omgezet te zijn naar CC-BY [1]. Je zou kunnen twijfelen of dit wel compatible is, maar (IANAL) waarschijnlijk is vermelding op de attribution pagina voldoende. Het Kadaster weet ook dat OSM geaggregeerd is uit allerlei bronnen, waaronder de vele duizenden mappers die veel energie hierin hebben gestoken. Misschien is dit voer voor legal-talk om dit helemaal uit te kristalliseren. Anyways, de onduidelijkheid die nog rest, wordt volledig weggevaagd door Ben Bruns. Hij heeft op diverse plekken uiting gegeven dat het wat hem betreft prima is dat BRT-data wordt hergebruikt binnen OSM of op andere plekken. Het Kadaster juicht dat juist toe. Gisteren was ik op een bijeenkomst waar hij dit nogmaals expliciet duidelijk heeft gemaakt. Als hij dat als product manager zegt, dan is dit ongetwijfeld waar. Let op, ik wil met dit bericht geen discussie opstarten over de import van BRT data in OSM, maar alleen dat hergebruik door het Kadaster, bij monde van Ben Bruns, wordt toegejuicht (mits vermelding op de attribution pagina). Gegeven de data van eerdere imports (AND, 3dShapes), zal het toevoegen hiervan een zeer grote inspanning vereisen! Dit geldt ook voor kleine gebieden! De actualiteit van TOP10NL is wel goed, aangezien het Kadaster erin geslaagd is om de productiecyclus zodanig te stroomlijnen dat de oudste bladen 2 jaar oud zijn. Dat betekent dat TOP10NL in het algemeen even oud of nieuwer is dan
[OSM-talk-nl] Gebruik data Basisregistratie Topografie
Hoi, Bij mij en diverse anderen was de indruk aanwezig dat data van de Basisregistratie Topografie (BRT) in OSM niet toegestaan is, omdat de licentie (CC-BY-SA) incompatible zou zijn met ODbL. De licentie van alle BRT-producten (vector én raster) blijkt geruime tijd geleden omgezet te zijn naar CC-BY [1]. Je zou kunnen twijfelen of dit wel compatible is, maar (IANAL) waarschijnlijk is vermelding op de attribution pagina voldoende. Het Kadaster weet ook dat OSM geaggregeerd is uit allerlei bronnen, waaronder de vele duizenden mappers die veel energie hierin hebben gestoken. Misschien is dit voer voor legal-talk om dit helemaal uit te kristalliseren. Anyways, de onduidelijkheid die nog rest, wordt volledig weggevaagd door Ben Bruns. Hij heeft op diverse plekken uiting gegeven dat het wat hem betreft prima is dat BRT-data wordt hergebruikt binnen OSM of op andere plekken. Het Kadaster juicht dat juist toe. Gisteren was ik op een bijeenkomst waar hij dit nogmaals expliciet duidelijk heeft gemaakt. Als hij dat als product manager zegt, dan is dit ongetwijfeld waar. Let op, ik wil met dit bericht geen discussie opstarten over de import van BRT data in OSM, maar alleen dat hergebruik door het Kadaster, bij monde van Ben Bruns, wordt toegejuicht (mits vermelding op de attribution pagina). Gegeven de data van eerdere imports (AND, 3dShapes), zal het toevoegen hiervan een zeer grote inspanning vereisen! Dit geldt ook voor kleine gebieden! De actualiteit van TOP10NL is wel goed, aangezien het Kadaster erin geslaagd is om de productiecyclus zodanig te stroomlijnen dat de oudste bladen 2 jaar oud zijn. Dat betekent dat TOP10NL in het algemeen even oud of nieuwer is dan de Bing-foto's, die grofweg van 2010 zijn. Verder een nieuwtje: het Kadaster is ook een paar jaar bezig geweest met het automatisch generaliseren van de TOP10NL data naar een schaal van 1:5. Een belangrijke fase hierin is afgerond, namelijk dat heel Nederland is omgezet en de rasterbeelden hiervan zijn vrijgegeven voor het publiek (uiteraard ook CC-BY). De data is bij het Kadaster aan te vragen, maar staat nog niet op PDOK. Uiteraard heb ik, in goede traditie, een aanvraag ingediend en de data ontvangen ;) Voor degenen die alvast willen kijken, heb ik alle bladen aan elkaar geplakt en op Gigapan gezet: http://gigapan.com/gigapans?query=top50raster. Het Kadaster hoort graag feedback, dus fouten kunnen gemeld worden. Het is nog niet duidelijk waar, maar hopelijk zal die vraag gauw beantwoord zal worden. Groeten, Frank [1] http://www.kadaster.nl/BRT ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Crowdsourcing...
Het mooie aan crowdsourcing is dat je veranderingen in de werkelijkheid binnen een paar dagen in de kaart kunt verwerken. Het minder mooie aan crowdsourcing is dat deze wijziging een paar dagen later weer door iemand anders ongedaan wordt gemaakt... ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Crowdsourcing...
On 13-6-2013 19:04, Lennard wrote: On 13-6-2013 19:01, Frank Steggink wrote: Het mooie aan crowdsourcing is dat je veranderingen in de werkelijkheid binnen een paar dagen in de kaart kunt verwerken. Het minder mooie aan crowdsourcing is dat deze wijziging een paar dagen later weer door iemand anders ongedaan wordt gemaakt... Gebaseerd op immer achter de feiten aanlopende lufo's ? Dat weet ik niet. Ik heb hem om uitleg gevraagd. Nu is het wel zo dat mijn aanpassing onlogisch voorkomt, maar het geeft wel de huidige situatie aan. In ieder geval heb ik de motivatie in het commentaar van mijn changeset aangegeven. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Staat licentie van top10nl importeren toe ?
On 15-2-2013 20:02, Top10NL Import wrote: Ik zit er over te denken om top10nl data te importen in Open Streetmap. Het gaat dan om wegen, fietspaden, zandwegen, paden, etc. Is dat toegestaan gezien de licentie van top10nl ? De licentie van Top10nl is namelijk CC-BY-SA 3.0. Voor Open Streetmap is dat ODbL http://opendatacommons.org/licenses/odbl/. Zie ook http://forum.openstreetmap.org/viewtopic.php?pid=313299#p313299. Is er expliciet toestemming nodig van het Kadaster ? Beste Top10NL Import, Afgezien van de vraag of de TOP10NL licentie compatible is met OSM (wat dus niet zo is), vraag ik me af wat is de meerwaarde van de import? Bijna alle wegen, die met de auto berijdbaar zijn, zitten er al in. Fiets- en voetpaden en zandwegen zitten er ook voor een groot deel in. Niet overal, maar wel meer dan genoeg om bruikbaar te zijn. Een ander feit is dat TOP10NL data één tot drie jaar achterloopt. De meest recente toevoegingen zijn gedaan op basis van luchtfoto's van 2011. TOP10NL heeft een herzieningscyclus van twee jaar. Ook kan niemand garanderen dat de data in TOP10NL compleet en juist is. Voor de nauwkeurigheid hoef je het ook niet te doen. TOP10NL wordt gemaakt voor kaarten op schaal 1:5000 tot 1:25000. Dat is zo'n beetje ook de nauwkeurigheid van wat nu in OSM zit. Misschien niet overal, maar het verschil is te weinig om een hele import op je nek te halen. Wat de hoeveelheid werk betreft, het wordt een crime om de data goed te integreren. Kortom, ik zou er niet eens aan denken. Verder vind ik het een slechte zet dat je je vraag anoniem stelt. Voor mij is dat een reden om je voorstel bij voorbaat niet te steunen. Wat heb je te verbergen? Anonimiteit past niet bij een open data project. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Staat licentie van top10nl importeren toe ?
On 15-2-2013 21:52, Frank Steggink wrote: On 15-2-2013 20:02, Top10NL Import wrote: Ik zit er over te denken om top10nl data te importen in Open Streetmap. Het gaat dan om wegen, fietspaden, zandwegen, paden, etc. Is dat toegestaan gezien de licentie van top10nl ? De licentie van Top10nl is namelijk CC-BY-SA 3.0. Voor Open Streetmap is dat ODbL http://opendatacommons.org/licenses/odbl/. Zie ook http://forum.openstreetmap.org/viewtopic.php?pid=313299#p313299. Is er expliciet toestemming nodig van het Kadaster ? Beste Top10NL Import, Afgezien van de vraag of de TOP10NL licentie compatible is met OSM (wat dus niet zo is), vraag ik me af wat is de meerwaarde van de import? Bijna alle wegen, die met de auto berijdbaar zijn, zitten er al in. Fiets- en voetpaden en zandwegen zitten er ook voor een groot deel in. Niet overal, maar wel meer dan genoeg om bruikbaar te zijn. Een ander feit is dat TOP10NL data één tot drie jaar achterloopt. De meest recente toevoegingen zijn gedaan op basis van luchtfoto's van 2011. TOP10NL heeft een herzieningscyclus van twee jaar. Ook kan niemand garanderen dat de data in TOP10NL compleet en juist is. Voor de nauwkeurigheid hoef je het ook niet te doen. TOP10NL wordt gemaakt voor kaarten op schaal 1:5000 tot 1:25000. Dat is zo'n beetje ook de nauwkeurigheid van wat nu in OSM zit. Misschien niet overal, maar het verschil is te weinig om een hele import op je nek te halen. Wat de hoeveelheid werk betreft, het wordt een crime om de data goed te integreren. Kortom, ik zou er niet eens aan denken. Verder vind ik het een slechte zet dat je je vraag anoniem stelt. Voor mij is dat een reden om je voorstel bij voorbaat niet te steunen. Wat heb je te verbergen? Anonimiteit past niet bij een open data project. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Kijk ook even hier, v.w.b. de huidige stand van zaken m.b.t. bospaden: http://www.kadaster.nl/web/file?uuid=1c8c2665-d016-4893-b0f3-b976d795562eowner=23cbe925-35ce-4a72-ac8c-a33a0c19ae1econtentid=1474 (Waarschuwing: PDF) Zie op pagina 19: Voor objecten die vanuit luchtfoto’s moeilijk waarneembaar zijn, bijvoorbeeld bospaden, overweegt het Kadaster om crowdsourcing toe te passen. In dit geval houdt dat in, dat vrijwilligers, bijvoorbeeld boswandelaars, geografische informatie over bepaalde objecten aan het Kadaster kunnen aanleveren. En: Vanaf 2014 zal de actualisering van de TOP10NL in toenemende mate gebaseerd worden op mutatietriggers vanuit externe bronnen die worden geverifieerd op actuele luchtfotografie. Dit is wel grappig. Straks gaat het Kadaster OSM in de gaten houden en gaan ze o.b.v. onze mutaties TOP10NL bijhouden ;) Dit is trouwens ook de werkwijze van National Resources Canada, die o.a. topografische kaarten maken voor Canada. Overigens kan Canadese topografische data wel worden geïmporteerd worden, omdat die PD is. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Bot-wars
On 11-12-2012 17:42, Sebastiaan Couwenberg wrote: Geef nou even een concreet voorbeeld. Ik gok dat ze het hebben over de geautomatiseerde edits van pschonmann, bv: http://www.openstreetmap.org/browse/changeset/14217588 Die vervolgens gerevert werden door woodpeck_repair, bv: http://www.openstreetmap.org/browse/changeset/14229400 Deze wereldwijde edits zag je voorbij komen in de History tab. Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Woodpeck-repair is een bot van Frederik Ramm. Als je zijn comment in de changeset leest, zie je waarom hij deze run heeft uitgevoerd: revert un-discussed world-wide mechanical edits. please note that 'deprecated' does not mean we want you to auto-edit world-wide (else we'd have done that alrady) Het is not done om automatisch deprecated tags zomaar te editen in wat anders. De kans dat een bot fouten maakt is ernstiger dan het vermeende probleem dat de auteur meent op te moeten lossen. Dat sommige gebruikers zoals pschonmann zich niet aan dat soort richtlijnen aantrekt, wil niet zeggen dat er een edit war is. Ik neem aan dat hij al op zijn gedrag door Frederik, de Data Working Group of anderen is aangesproken. Frederik en een aantal anderen hebben bewezen genoeg skills te hebben en het vertrouwen van de community in het algemeen te hebben om dit soort acties van anderen ongedaan te maken. Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Bing-update in Duitsland
Hoi, Voor wie het nog niet gemerkt heeft: de afgelopen week hebben onze oosterburen een update gekregen van de Bing-luchtfoto's. Tot voor kort werden grote delen van Duitsland alleen door Landsat bestreken, maar gelukkig is dat nu veranderd. Dus goed nieuws voor iedereen die wel eens over de grens aan het werk is in OSM. :) Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] wegen in drievoud
JOSM heeft soms last van deze kuren. Het is mij ook wel eens overkomen. Je kunt als je met relaties of andere complexe zaken aan de gang gaat beter vaker uploaden. Je kunt in JOSM er ook voor kiezen om de changeset niet af te sluiten, dus ook al doe je veel veranderingen, dan komen ze in dezelfde changeset. OSM sluit de changeset automatisch nadat een uur geen wijzigingen zijn veranderd. Je kunt dat doen in het upload-scherm. Frank On 21-10-2012 10:53, Hugo Holscher wrote: Ik heb ook iets dergelijks meegemaakt. Wat ik er van geleerd heb, is een tag mee te geven (in bijvoorbeeld een note als dat kan), waarmee je, je eigen wijziging kunt selecteren en veranderen. Maar misschien had dat in dit specifieke geval niet geholpen. Hugo *From:* dbuss...@goudappel.nl mailto:dbuss...@goudappel.nl *Sent:* Saturday, October 20, 2012 10:47 PM *To:* OpenStreetMap NL discussion list mailto:talk-nl@openstreetmap.org *Subject:* Re: [OSM-talk-nl] wegen in drievoud Vreemd verhaal. Ik moest alles handmatig herstellen omdat door de dubbeling de relaties (bus en fietsknopen) zo in de war waren dat terugdraaien geen optie meer was. Bljikbaar was iemand anders tegelijk of net na mij met de buslijnen bezig op mijn drievoudige wegen... Nu is volgens mij alles weer netjes. Vervolgens ben ik op zoek gegaan of er elders dubbele wegen zijn maar kon er geen vinden. Het is dus niet zo dat JOSM dit vaker doet maar een idee hoe deze changeset kon ontstaan heb ik nog steeds niet. -Johan C osm...@gmail.com schreef: - Aan: OpenStreetMap NL discussion list talk-nl@openstreetmap.org Van: Johan C osm...@gmail.com Datum: 10/20/2012 04:22PM Onderwerp: Re: [OSM-talk-nl] wegen in drievoud Ik zie twee mogelijkheden: 1. terugdraaien 2. checken met de validator en de crossing ways handmatig verwijderen Op 20 oktober 2012 01:31 schreef dbuss...@goudappel.nl mailto:dbuss...@goudappel.nl het volgende: vandaag iets te enthousiast teveel tegelijk in een changeset gepackt. JOSM heeft daarop een aantal keren timeout gegeven tot het uiteindelijk gelukt is. Effect is nu dat alle objecten die ik geraakt heb drie keer boven elkaar in OSM staan. Weet iemand hoe dat komt en of het eenvoudig ongedaan gemaakt kan worden? Het gaat om http://www.openstreetmap.org/browse/changeset/13561955 Voorbeeld: de volgende ways (allen behorende tot changeset 13561955) zijn identiek: http://www.openstreetmap.org/browse/way/186703099 http://www.openstreetmap.org/browse/way/186691521 http://www.openstreetmap.org/browse/way/186693939 Groeten, Dirk Disclaimer De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. De afzender sluit iedere aansprakelijkheid uit die voortvloeit uit elektronische verzending. ___ Talk-nl mailing list Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Disclaimer De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. De afzender sluit iedere aansprakelijkheid uit die voortvloeit uit elektronische verzending. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Het taggen van BAG data.
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? 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 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
Re: [OSM-talk-nl] Het taggen van BAG data.
Dat zou je kunnen melden via het terugmeldformulier. Frank On 21-10-2012 11:51, Minko wrote: Het omgekeerde komt ook voor, panden die wel bestaan maar niet in de BAG voorkomen. Bv restaurant Dara (uit 2009): http://www.openstreetmap.org/?way=186870059 Is dat een bekend fenomeen? 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. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG data en de Import Guidelines
On 21-10-2012 16:04, Sebastiaan Couwenberg wrote: Nu de discussies over het importeren van BAG data goed op gang komen heb ik eens gekeken hoe hiervoor rekening te houden met de Import Guidelines [1]. We zijn al een heel eind op weg wat dat betreft, maar nog niet aan alle details is al invulling gegeven. [1] http://wiki.openstreetmap.org/wiki/Import/Guidelines De checklist noemt acht punten om rekening mee te houden. 1. Gain familiarity with the basics of OpenStreetMap, including editing, such as adding details of your neighbourhood. Consider following the beginners' guide. Ieder van ons voldoet aan dit criterium. Het is inderdaad niet verstandig als nieuwe mappers direct aan de slag gaan met BAG data voordat we hier een beginners vriendelijke handleiding voor hebben opgesteld. 2. Contact the relevant local OSM community to make sure you're not heading down a path someone else has tried and to get a sense of how receptive the community is to imports. Check for local user groups, local chapters, and country-specific mailing lists. De discussies met de lokale community zijn gestart op de mailinglist [2] en forum [3], en de reacties tot nu zijn nog niet echt negatief. Ik verwacht geen bezwaar van de NL community tegen de BAG imports zolang de uitvoering hiervan geen problemen gaat verzorgen. Zolang de BAG panden maar geen custom edits verwijderen, en BAG woonplaats grenzen de bestaanden kunnen aanpassen ipv vervangen lijkt mij de weg vrij. Maar het is ook nog wat vroeg om over duidelijke consensus te spreken. Nog niet veel verschillende mensen hebben zich in de discussies gemengd. Veel meer mensen verwacht eerlijk gezegd ook niet echt, er zijn niet erg veel NL mappers die zich ook nog eens met de community communicatie bezig houden lijkt het. [2] http://lists.openstreetmap.org/pipermail/talk-nl/2012-October/014215.html [3] http://forum.openstreetmap.org/viewtopic.php?id=18311 3. Check the license of the data. If the license of the data is not compatible with the OpenStreetMap license, you can not use the data. De open data portal van de Nederlandse overheid [4] is heel expliet in de vrije licensering van de BAG data. Licentie: Publiek Domein. [4] https://data.overheid.nl/data/dataset/basisregistratie-adressen-en-gebouwen-bag- Op de home page van de open data portal staat dit wat uitgebreider: http://lists.openstreetmap.org/pipermail/talk/2012-October/064868.html Wat is open data? * De data is openbaar; * Er berust geen auteursrecht of andere rechten van derden op; * De data zijn bekostigd uit publieke middelen, beschikbaar gesteld voor de uitvoering van die taak; * De data voldoen bij voorkeur aan ‘open standaarden’ (geen barrières voor het gebruik door ICT-gebruikers of door ICT-aanbieders); * Open Data is bij voorkeur computer-leesbaar, zodat zoekmachines informatie in documenten kunnen vinden. De situatie rond de postcode is mogelijk nog wel een struikelblok. Ondank dat de overheid de data vrij geeft, procederen PostNL en Cendris nog steeds tegen het vrij geven van de postcode database. Zie de dreigbrief tegen postcodeatlas.nl: http://www.postcodeatlas.nl/pages/postcodebestand.html In het vonnis van 21 december 2011 [5] word gesteld dat de postcodes die de overheid van PostNL krijgt niet uit het postcodebestand van PostNL noch de postcodetabel van Cendris komen, en de databaserechten die beide partijen hebben niet van toepassing zijn op de postcodes in de BAG. Dat na de privatisering van de PTT het toewijzen van postcodes niet meer door een overheidsinstantie gedaan word maakt het tot een vreemde situatie. Alle drie partijen stellen nu hun eigen database op met de gegevens die zijn gezamenlijk vast stellen zoals ze dat vroeger als staatsbedrijf onder een dak deden. De BAG database van de overheid word duidelijk als losstaand werk gezien, wat geen afgeleide is van de postcode databases van PostNL en Cendris. Het vonnis word nader toegelicht in Jurispundentie Nr 1 [6]. [5] http://zoeken.rechtspraak.nl/detailpage.aspx?ljn=BU9147 [6] http://www.ivir.nl/publicaties/eechoud/Annotatie_Mf_2012_4.pdf Mocht in het beroep dat PostNL heeft aangetekend tegen dit vonnis geoordeeld worden dat PostNL toch rechten heeft op de postcodes in de BAG, dan verwacht ik dat de overheid licentiegelden aan PostNL zal gaan betalen voor het gebruik van de postcodes. Wat OSM betreft zullen we de postcodes dan mogelijk achterwege moeten laten bij het importeren indien de postcodes uit de BAG niet vrijelijk gebruikt mogen worden. Ik kan alleen geen informatie vinden over het beroep wat PostNL tegen het vonnis zou hebben aangetekend. Heeft iemand meer informatie over de huidige stand van zake in deze zaak? 4. Find out what data layers the organization offers. This might be street centerlines, building outlines, waterways, addresses, etc. Gebouwen, adressen en administratieve grenzen. Binnen de BAG bekend als de PND, NUM en WPL data
Re: [OSM-talk-nl] Oude topografische kaarten
On 12-9-2012 11:51, Paul Smits wrote: Het zou ook van pas kunnen komen bij humanitaire mapping. Kunnen goede aanwijzingen zijn voor wegen in afgelegen gebieden. Bijvoorbeeld http://tasks.hotosm.org/job/47 Is er een kans dat deze russische kaarten als WMS beschikbaar komen voor bijvoorbeeld JOSM? Op 12 september 2012 10:38 schreef Maarten Deen md...@xs4all.nl mailto:md...@xs4all.nl het volgende: On 2012-09-12 09:38, Frank Fesevur wrote: Op 12 september 2012 08:01 heeft Maarten Deen het volgende geschreven: Ik weet niet of het hier al een keer genoemd is, maar op http://www.topomapper.com kun je oude topografische kaarten zien, en ook split-screen vergelijken met de huidige situatie in o.a. OSM. Zijn inderdaad oude kaarten, ik gok jaren 80. Dan pas zie je hoeveel er bijvoorbeeld in en om Den Haag is bijgebouwd. Nog daarvoor. Als ik op http://www.autosnelwegen.nl/asw/netw/netwerk2.htm kijk en zie dat de A50 onder Valburg alleen nog als stippellijn is ingetekend en de A28 vanaf Meppel ontbreekt (daar is wel een andere kaart gebruikt), en de A50 van Den Bosch naar Heesch er wel al is, dan is het stand 1975. In JOSM is het al mogelijk om een WMS-laag of tiles-laag (TMS) toe te voegen. In het specifieke geval van topomapper ligt het anders, omdat dit gebruik maakt van het tiled WMS protocol. Het request wordt aan TileCache gedaan (een applicatie die tiles uit WMS genereert en cachet). Hierdoor heb je wel de extent van de tiles nodig zoals in WMS, maar je bent gebonden aan de tile-indeling. Ik weet niet of JOSM dit ondersteunt. Ik zie geen voorbeeld met TileCache in de lijst met WMS / TMS. Misschien kan TileCache ook op een andere manier aangesproken worden (dus met x, y en zoom, zoals de OSM tiles), maar ik ben hier niet in thuis. In theorie is het natuurlijk mogelijk om oude kaarten te gebruiken om daar informatie vandaan te halen. Je moet dan wel alert zijn op de volgende zaken: * Ouderdom: de meeste topografische kaarten die beschikbaar zijn van afgelegen gebieden zijn vaak al tientallen jaren oud. De kans is groot dat de situatie is veranderd. * Kwaliteit: je weet niet zeker wat de kwaliteit van de kaart is. Ik heb met Topomapper een stukje in de D.R. Congo vergeleken met OSM. De situatie kwam niet erg overeen. In ieder geval was op die plek al OSM data beschikbaar. * Copyright: vaak rust er copyright op kaarten, dus je kunt ze niet zomaar gebruiken. In het geval van de Sovjet-kaarten is dat anders, omdat de USSR nooit de Conventie van Bern heeft ondertekend. Let op: op de meer gedetailleerde West-europese kaarten (1:200.000 en groter) rust wel copyright, omdat bewezen is dat de kaarten zijn overgetekend van de Ordnance Survey, etc. Als je oude kaarten hebt, moeten ze wel worden gegeorefereerd, geherprojecteerd danwel gewarped en opgeknipt worden in tiles. Hiermee houd ik me nu en dan bezig (ter afwisseling van OSM ;) ). Een oud voorbeeldje staat nog hier: http://steggink.org/mtbl/. Dit toont zgn. Messtischblätter, oude Duitse topografische kaarten. Dit is de werkwijze die ik volg: * Georefereren (toekennen van coördinaten aan bepaalde pixels): dit kost een hoop tijd. Er zijn wel kaarten te vinden die MAP-files hebben. Dit zijn een soort van georeferentie-bestanden die door OZI Explorer gebruikt worden. Met de trial editie kun je wel kaarten georefereren. Je moet ten eerste een coördinatenstelsel opgeven. Dit kan een probleem zijn voor oude kaarten, omdat daarvoor stelsels werden gebruikt die niet door OZI Explorer ondersteund worden. Dan moet je maar wat kiezen wat in de buurt ligt. Bijv. voor het vastleggen van latlon WGS84 gebruiken, i.p.v. Hayford of Clarke 1866. En voor het vastleggen van XY-coördinaten van geprojecteerde stelsels de UTM-velden gebruiken en daar een fake zone invullen. In OZI Explorer kun je max. 9 punten opgeven. Die prik je in de kaart en je vult dan de bijbehorende coördinaten in (latlon of XY). * Herprojecteren: ik heb een programmaatje gemaakt die de MAP-files uitleest naar een ander formaat. In het begin worden de coördinatenstelsels als WKT gedefinieerd. Hier wordt later naar verwezen. Ik vervang de WKT-tekst door wat anders, en zoek/vervang de verwijzingen. Dan het herprojecteren zelf: ook via een eigen gemaakt command line tooltje. Dit leest het configuratiebestand uit. Je kunt hierin de bounding box, resolutie en coördinatenstelsel opgeven. Voor gebruik in OpenLayers is dat vaak Web Mercator, maar het kan ook RD, etc. zijn. Soms kan dit heel lang duren, vooral als je een kaart met een hoge resolutie wilt maken. Alle berekeningen (warpen, herprojectie, bepalen resolutie) voer ik achter elkaar uit, zodat voor elke pixel in het doelbestand ik maar 1x data uit de bronbestanden hoef te lezen. Anders gaat dat zwaar ten koste van de kwaliteit, zoals je bijv. op Topomapper kunt zien. Je moet hier
Re: [OSM-talk-nl] Oude topografische kaarten
On 13-9-2012 11:22, Frank Steggink wrote: On 12-9-2012 11:51, Paul Smits wrote: Het zou ook van pas kunnen komen bij humanitaire mapping. Kunnen goede aanwijzingen zijn voor wegen in afgelegen gebieden. Bijvoorbeeld http://tasks.hotosm.org/job/47 Is er een kans dat deze russische kaarten als WMS beschikbaar komen voor bijvoorbeeld JOSM? Op 12 september 2012 10:38 schreef Maarten Deen md...@xs4all.nl mailto:md...@xs4all.nl het volgende: On 2012-09-12 09:38, Frank Fesevur wrote: Op 12 september 2012 08:01 heeft Maarten Deen het volgende geschreven: Ik weet niet of het hier al een keer genoemd is, maar op http://www.topomapper.com kun je oude topografische kaarten zien, en ook split-screen vergelijken met de huidige situatie in o.a. OSM. Zijn inderdaad oude kaarten, ik gok jaren 80. Dan pas zie je hoeveel er bijvoorbeeld in en om Den Haag is bijgebouwd. Nog daarvoor. Als ik op http://www.autosnelwegen.nl/asw/netw/netwerk2.htm kijk en zie dat de A50 onder Valburg alleen nog als stippellijn is ingetekend en de A28 vanaf Meppel ontbreekt (daar is wel een andere kaart gebruikt), en de A50 van Den Bosch naar Heesch er wel al is, dan is het stand 1975. In JOSM is het al mogelijk om een WMS-laag of tiles-laag (TMS) toe te voegen. In het specifieke geval van topomapper ligt het anders, omdat dit gebruik maakt van het tiled WMS protocol. Het request wordt aan TileCache gedaan (een applicatie die tiles uit WMS genereert en cachet). Hierdoor heb je wel de extent van de tiles nodig zoals in WMS, maar je bent gebonden aan de tile-indeling. Ik weet niet of JOSM dit ondersteunt. Ik zie geen voorbeeld met TileCache in de lijst met WMS / TMS. Misschien kan TileCache ook op een andere manier aangesproken worden (dus met x, y en zoom, zoals de OSM tiles), maar ik ben hier niet in thuis. In theorie is het natuurlijk mogelijk om oude kaarten te gebruiken om daar informatie vandaan te halen. Je moet dan wel alert zijn op de volgende zaken: * Ouderdom: de meeste topografische kaarten die beschikbaar zijn van afgelegen gebieden zijn vaak al tientallen jaren oud. De kans is groot dat de situatie is veranderd. * Kwaliteit: je weet niet zeker wat de kwaliteit van de kaart is. Ik heb met Topomapper een stukje in de D.R. Congo vergeleken met OSM. De situatie kwam niet erg overeen. In ieder geval was op die plek al OSM data beschikbaar. * Copyright: vaak rust er copyright op kaarten, dus je kunt ze niet zomaar gebruiken. In het geval van de Sovjet-kaarten is dat anders, omdat de USSR nooit de Conventie van Bern heeft ondertekend. Let op: op de meer gedetailleerde West-europese kaarten (1:200.000 en groter) rust wel copyright, omdat bewezen is dat de kaarten zijn overgetekend van de Ordnance Survey, etc. Als je oude kaarten hebt, moeten ze wel worden gegeorefereerd, geherprojecteerd danwel gewarped en opgeknipt worden in tiles. Hiermee houd ik me nu en dan bezig (ter afwisseling van OSM ;) ). Een oud voorbeeldje staat nog hier: http://steggink.org/mtbl/. Dit toont zgn. Messtischblätter, oude Duitse topografische kaarten. Dit is de werkwijze die ik volg: * Georefereren (toekennen van coördinaten aan bepaalde pixels): dit kost een hoop tijd. Er zijn wel kaarten te vinden die MAP-files hebben. Dit zijn een soort van georeferentie-bestanden die door OZI Explorer gebruikt worden. Met de trial editie kun je wel kaarten georefereren. Je moet ten eerste een coördinatenstelsel opgeven. Dit kan een probleem zijn voor oude kaarten, omdat daarvoor stelsels werden gebruikt die niet door OZI Explorer ondersteund worden. Dan moet je maar wat kiezen wat in de buurt ligt. Bijv. voor het vastleggen van latlon WGS84 gebruiken, i.p.v. Hayford of Clarke 1866. En voor het vastleggen van XY-coördinaten van geprojecteerde stelsels de UTM-velden gebruiken en daar een fake zone invullen. In OZI Explorer kun je max. 9 punten opgeven. Die prik je in de kaart en je vult dan de bijbehorende coördinaten in (latlon of XY). * Herprojecteren: ik heb een programmaatje gemaakt die de MAP-files uitleest naar een ander formaat. In het begin worden de coördinatenstelsels als WKT gedefinieerd. Hier wordt later naar verwezen. Ik vervang de WKT-tekst door wat anders, en zoek/vervang de verwijzingen. Dan het herprojecteren zelf: ook via een eigen gemaakt command line tooltje. Dit leest het configuratiebestand uit. Je kunt hierin de bounding box, resolutie en coördinatenstelsel opgeven. Voor gebruik in OpenLayers is dat vaak Web Mercator, maar het kan ook RD, etc. zijn. Soms kan dit heel lang duren, vooral als je een kaart met een hoge resolutie wilt maken. Alle berekeningen (warpen, herprojectie, bepalen resolutie) voer ik achter elkaar uit, zodat voor elke pixel in het doelbestand ik maar 1x data uit de bronbestanden hoef te lezen. Anders gaat dat zwaar ten koste van de kwaliteit, zoals je
Re: [OSM-talk-nl] Nieuwe maximumsnelheden op snelwegen
On 4-9-2012 9:56, Maarten Deen wrote: On 2012-09-03 20:42, 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? In de geest van http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions: maxspeed=130 maxspeed:conditional=100 @ open spitsstrook Maar ik vraag me af of je dat soort dingen echt wil taggen. Dit is alleen nuttig voor navigatiesystemen en die weten ook niet of een spitsstrook open is of niet en kunnen die snelheid dus niet tonen. Om er nog niet van te spreken dat het er alleen maar toe leidt dat mensen nog minder op borden gaan kijken en het dus een promotie van slecht weggedrag is. Laat duidelijk zijn dat ik voor een levenslang rijverbod pleit voor al dat soort wegmisbruikers die in dat soort berichten staan van auto rijdt rivier in omdat de navigatie dat zegt. Krijgen we trouwens wel een variabele maximumsnelheid.openstreetmap.nl kaart? Dus eentje die van 6 tot 19 een andere snelheid toont dan van 19 tot 6? ;) Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Dan wil ik ook versies voor inhaalverboden voor vrachtauto's, voor het geval ik mijn vrachtwagenrijbewijs haal. Verder een voor slecht weer (snelheidsrestricties bij nat wegdek), etc. Of op borden kijken helpt, weet ik niet. Op de parallelbaan bij knooppunt Hoevelaken op de A1 van Hengelo naar Amsterdam viel me het volgende op. 1. Snelheidsrestrictie 100 km/u 2. Snelheidsrestrictie 70 km/u bij nat wegdek 3. 120 km/u (nieuw bord) - staat echt op de parallelbaan 4. Einde snelheidsrestrictie 70 km/u bij nat wegdek 5. 100 km/u, nadat de baan vanaf de A28 vanuit Zwolle is bijgevoegd Na samenvoegen parallelbaan op hoofdrijbaan: 120 km/u (nieuw bord), volgens mij nog met onderbord 6-19 uur... Dit alles is over een traject van zo'n 2 km. Wat is nu de snelheid bij droog weer tussen bord 3 en 5? Ik heb me al eerder afgevraagd hoe nat een wegdek moet zijn voor sommige extra snelheidsbeperkingen. Is het als het een beetje vochtig is, of als er water uitspat als je er overheen rijdt, of moet er blank water op staan? Alhoewel ik zelf wel van een beetje doorrijden houd, vind ik dit gewoon een verkiezingsstunt. Ook al heeft Melanie dit aangekondigd voordat ome Geert de stekker eruit trak... (Weet ik niet zeker, het was rond dezelfde tijd.) De overheid zit het land dood te gooien met allerlei regeltjes. Er kan veel beter een beroep worden gedaan op het gezonde verstand van automobilisten. En voor degenen die dat niet hebben: die horen niet op de weg thuis. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] openkvk bedrijfsnamen / geolocaties bulkimporteren?
Ctrl+C en dan Shift+Ctrl+V (paste tags only). Als dat teveel goede tags overschrijft, ga dan naar http://josm.openstreetmap.de/newticket Frank On 3-8-2012 23:43, Robert Elsenaar wrote: Voor een dergelijke osm file heb ik ook meer dan belangstelling. Voor de mergel activiteiten zou eigenlijk een mooie functie in JOSM moeten zijn. Met vriendelijke groeten Robert Elsenaar Frank Steggink stegg...@steggink.org schreef: Quoting Stefan de Konink ste...@konink.de: Dit weekend zal er weer een update van openkvk plaatsvinden. Al eerder hebben we veel adressen kunnen koppelen met de BAG. Daarmee zijn geolocaties eenvoudig te onttrekken. Zou er belangstelling zijn om automatisch een PoI import te doen met data uit openkvk, waar beschikbaar inclusief amenity? Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Automatisch importeren lijkt me sowieso niet wenselijk, onder meer vanwege het risico op duplicates. Wat je beter zou kunnen doen is OSM-files beschikbaar stellen met deze amenities, uitgesplitst naar 4-cijferig postcodegebied. Dan kunnen deze handmatig gemerged worden met de al aanwezige info. Dit gaat jouw wel lukken :) Hiervoor heb ik wel belangstelling. Ik denk dat het verstandig is om eerst de mapping van OpenKVK naar OSM apart te bespreken. Welk voorstel heb je hiervoor klaarliggen? Groeten, Frank ___ 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] openkvk bedrijfsnamen / geolocaties bulkimporteren?
Quoting Stefan de Konink ste...@konink.de: Dit weekend zal er weer een update van openkvk plaatsvinden. Al eerder hebben we veel adressen kunnen koppelen met de BAG. Daarmee zijn geolocaties eenvoudig te onttrekken. Zou er belangstelling zijn om automatisch een PoI import te doen met data uit openkvk, waar beschikbaar inclusief amenity? Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Automatisch importeren lijkt me sowieso niet wenselijk, onder meer vanwege het risico op duplicates. Wat je beter zou kunnen doen is OSM-files beschikbaar stellen met deze amenities, uitgesplitst naar 4-cijferig postcodegebied. Dan kunnen deze handmatig gemerged worden met de al aanwezige info. Dit gaat jouw wel lukken :) Hiervoor heb ik wel belangstelling. Ik denk dat het verstandig is om eerst de mapping van OpenKVK naar OSM apart te bespreken. Welk voorstel heb je hiervoor klaarliggen? Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Maandelijkse geo-borrels in Utrecht
Hoi Robert, Iemand van OSGeo.nl heeft voorgesteld om de borrel in een café bij station Driebergen-Zeist te houden. Wellicht beter bereikbaar met je heilige koe. (Een stalen ros is volgens mij gewoon een fiets ;)) Dit omdat er ook geluiden waren om in/rond Wageningen iets te organiseren. Anyways, er is nog niks vastgelegd. Utrecht was gewoon een voorstel, omdat het centraal ligt en ik er woon. Tegen de tijd dat het zover is, hakken we de knoop wel door :) Frank On 29-6-2012 12:11, Robert Elsenaar wrote: Frank, Fijn je weer actief terug te zien. Zo heb ik je leren kennen en zo heb ik je leren waarderen. Wat ik op amsterdam tegen heb is dat je er onmogelijk per auto kunt komen. Wil je mij in Utrecht regelmatig tegen komen, ga dan niet in het centrum zitten, of zorg in iedetgeval dat er een betaalbaar plekje voor mijn stalen ros aanwezig is. Ik hoop tot snel. Met vriendelijke groeten Robert Elsenaar Frank Steggink stegg...@steggink.org schreef: Hoi, Ik wil graag maandelijks een geo-borrel organiseren in Utrecht. Deze is bedoeld om gezellig met elkaar te praten over open data en open source software op geo-gebied. Uiteraard is OSM een van de belangrijkste topics ;) De borrel is er op gericht om open (source/data) geo-kennis in Midden-Nederland bij elkaar te brengen. Dus als je hier woont en/of werkt, of als je het geen bezwaar vindt om van verder weg langs te komen, dan ben je van harte uitgenodigd! Het tijdstip is de laatste donderdag van de maand, zodat we niet in het vaarwater zitten van de Amsterdamse Mappersborrel. Ik denk dat 19:00 uur een goed moment is om open te gaan. Eventueel kunnen we eerst ergens eten, want iedereen komt terug van een lange werk-/studiedag. De locatie moeten we nog bepalen, dus als je een goede suggestie hebt, met name waar de muziek op donderdagavond niet te luid staat, laat het me dan s.v.p. weten. Een vaste locatie is wel zo praktisch, maar uiteraard kunnen we ook wel eens 'verhuizen'. De eerste borrel wil ik op donderdag 30 augustus organiseren, i.v.m. de vakantie. Eventueel kunnen we een proefdraaisessie organiseren op 26 juli a.s. Via de osgeo.nl meetup groep heb ik een meeting opgezet voor de 30e augustus: http://www.meetup.com/OSGeoNL/events/71140362/. Laat s.v.p. daar weten of je komt. Ik ga ook de wiki-pagina [1] http://wiki.openstreetmap.org/wiki/Utrecht op osm.org van Utrecht bijwerken, zodat je je ook daar kunt opgeven en niet een meetup-account hoeft aan te maken. De aanleiding van deze borrel is een oproep van Just van den Broecke op de zeer geslaagde eerste OSGeo.nl meeting (nederlandstalige open source geo-organisatie) in Velp om meer regionale meetings te houden. De OSGeo.nl conferentie was bijzonder interessant. OSM kwam regelmatig aan bod. Ook ons aller Henk hield een presentatie en Milo van der Linden heeft een workshop OSM gehouden. Het mooiste om te horen vond ik een presentatie van iemand van de veiligheidsregio Fryslân, waarin hij vertelde dat zij OSM als basislaag gebruikten, maar als de hulpmedewerkers (o.a. brandweermensen) fouten constateerden in de data, ze deze ook gingen aanpassen, zodat de volgende keer de kaart correct is! Kijk, dit soort toepassingen, met feedback van gebruikers van onze data, maakt OSM zo'n fantastisch project :) Groeten, Frank [1] http://wiki.openstreetmap.org/wiki/Utrecht ___ 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] Iemand op 5 juli 's middags tijd voor Situatie gewijzigd: Navigatie aan!
Hetzelfde geldt voor mij. Vandaag met een nieuwe klus begonnen, dus het lijkt me niet handig om in de 1e week een halve dag vrij te nemen. Ik ben benieuwd of alle wegbeheerders (dus niet alleen RWS, maar ook gemeenten en provincies) hieraan gaan meedoen. Afgelopen vrijdag had ik een discussie met een collega hierover. Hij heeft een blauwe maandag bijgedragen aan de Fietsrouteplanner. Zij hebben een systeem om tijdelijke blokkades in te voeren. Zoiets zou eigenlijk ook in OSM moeten komen, maar dat is een ander verhaal. Frank On 2-7-2012 10:09, Henk Hoff wrote: Zeker een interessante bijeenkomst waarbij OSM aanwezig zou moeten zijn. Ik kan zelf helaas niet, heb al teveel dagen vrij genomen de afgelopen tijd. Mocht iemand tijd en zin hebben, wil die hem/haar van harte aanmoedigen te gaan! Gr, Henk Hoff 2012/7/1 Stefan de Konink ste...@konink.de mailto:ste...@konink.de Komende donderdagmiddag vanaf 14:30 is er in Utrecht een congres over de digitale bekendmakingen van onder andere IM. Op die manier kunnen kaartenboeren direct hun kaarten updaten op het moment dat er wegopbrekingen zijn of dat er iets is gewijzigd is het verkeersplan. Ik ben uitgenodigd ook door m'n bijdrage bij openOV, mocht er een OpenStreetMapper mee willen, mail even, er is plek ;) Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Andere tijden
Volgens mij is deze discussie erg OT aan het raken. Robert: CC-0 is binnen de OSM community bij velen wel bekend. Meer informatie hier: http://creativecommons.org/choose/zero/?lang=nl. Het komt overeen met Public Domain (PD). Frank On 25-5-2012 22:38, 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
[OSM-talk-nl] Andere tijden
Genietend van het mooie weer en de vakantie die ik toevallig heb, besloot ik maar weer e.e.a. in kaart te brengen in de prachtige stad Utrecht. Ondanks de mapping party van 2 jaar geleden is er nog meer dan genoeg te mappen. Wandelend langs de Oudegracht kwam ik toevallig uit bij een schim uit een ver verleden: een platenzaak [1]! Groot was zojuist mijn ontsteltenis bij het invoeren dat er hiervoor geen shop-tag was gedefinieerd! Blijkbaar heeft niemand hiervoor de moeite genomen in de tijd van iTunes. Volgens TagWatch [2] is een platenzaak sowieso een uitstervend verschijnsel. Culturel erfgoed? De kaart ziet er saai uit: alleen maar een lange reeks huisnummers. Er zitten hier wel woonhuizen, maar ook wel winkels (antiek, galerij, iets voor volwassenen, etc.) en een groot hok op nr. 312 [3] waar nog geen witte rook uitkomt. Groeten, Frank [1] http://www.openstreetmap.org/browse/node/1763428067 [2] http://taginfo.openstreetmap.org/keys/?key=shop#values , zoek op 'record' [3] http://www.openstreetmap.org/browse/node/1763427942 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Andere tijden
On 23-5-2012 21:38, Martijn van Exel wrote: Ik heb shop=music gebruikt in het verleden: http://taginfo.openstreetmap.org/tags/shop=music#overview http://wiki.openstreetmap.org/wiki/Proposed_features/Music_shop Aangepast. Ik blijf tagging een uitdaging vinden. O.a. een winkel met new-agespulletjes tegengekomen en een 'spellenspeciaalzaak' (verkopen Magic The Gathering-kaarten, etc.). Ik heb hen beloofd om ze niet als speelgoedwinkel op te nemen, dus nu is het shop=card_games ;) Bij twijfel gebruik ik tag watch, om gewoon aan te sluiten wat het meest gebruikelijk is. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] State of the Map in Tokyo Goedkope vluchten
On 19-5-2012 3:30, Henk Hoff wrote: Hallo allen, Mocht je interesse hebben om in september naar Tokyo te gaan voor State of the Map. (www.stateofthemap.org http://www.stateofthemap.org) Er is dit weekend nog een hele leuke actie voor goedkope tickets naar Tokyo. Alitalia heeft goedkope tickets naar Tokyo. En tot zondag kun je ook nog eens 20% extra korting krijgen. http://hukd.mydealz.de/deals/20-rabatt-bei-alitalia-tokio-flüge-nun-89741 http://hukd.mydealz.de/deals/20-rabatt-bei-alitalia-tokio-fl%C3%BCge-nun-89741 Ik heb deze net gedaan en het werkt. Je moet alleen even via alitalia.de http://alitalia.de boeken wil je de 20% korting kunnen krijgen. Mijn route: Amsterdam (Rome) Tokyo met Alitalia Tokyo (Rome) Boedapest met Alitalia Boedapest - Eindhoven met Whizzair Totaalprijs: 320 euro. Gr, Henk ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Henk, Heb je toevallig de laatste tijd nog iets meegekregen van een mogelijke SotM-EU? Aan de ene kant zou ik best wel Japan willen bezoeken, maar aan de andere kant zie ik als een Fuji-san op tegen de lange vlucht (+ douane-gedoe op het vliegveld), dus laat ik de internationale editie schieten. Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] AND data in OSM
On 5-4-2012 20:55, Henk Hoff wrote: Die voorwaarde heeft AND gesteld. Aangezien AND de goedkeuring voor gebruik van de data enkel het deel betreft wat reeds in onze database was gelezen, vonden we (de licentie werkgroep) dit geen belemmerende eis. Gr, Henk 2012/4/5 Stefan de Konink ste...@konink.de mailto:ste...@konink.de On 05-04-12 15:38, Henk Hoff wrote: Wanneer er nog vragen zijn, stuur me even een mailtje. Waarom moeten bron bestanden die onder de CC-BY-SA zijn vrijgegeven worden verwijderd? Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Wat is er in 2007 precies met AND afgesproken? Hebben zij de bronbestanden onder CC-BY-SA vrijgegeven, of was er een soortgelijke overeenkomst als met Bing, nl. dat hun data als input voor OSM gebruikt kan worden (wat dan onder CC-BY-SA zou vallen)? In de bronnen op de wiki-pagina [1] die nog online zijn, kom ik niet meer tegen dan dat het beschikbaar gesteld is. Dit is inclusief de press release van AND [2]. Groeten, Frank [1] http://wiki.openstreetmap.org/wiki/AND_Data [2] http://web.archive.org/web/20070927051801/http://www.and.com/company/newsletter/newsletter10/art01en.php ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Toponym
Citeren Frank Steggink stegg...@steggink.org: Citeren Maarten Deen md...@xs4all.nl: On 2012-03-23 08:56, Colin Smale wrote: Op dit moment wordt op een paar duizend plekken de tag toponym gebruikt, waarvan bij allemaal in Nederland. Maar wat ik zie in de waarden zijn volgens mij helemaal geen toponiemen! park, forest etc. zijn geen toponiemen maar voorbeelden van landgebruik/dekking. Julianapark en Zwarte Woud zouden wel toponiemen zijn. Of begrijp ik het woord toponym verkeerd? Ik zag dat er in feb 2010 een discussie was over detail omgeving oldenzaal waarin melding werd gemaakt van een nieuw voorstel voor toponiem-gebruik, en er is ook een Nederlandse Wiki-pagina [1] die daar heel kort iets over zegt waarin de basis wordt gelegd voor dit (IMHO) misbruik van de term. T.a.v. de toponym-tag heb ik de volgende constateringen: 1) Het is bijna uitsluitend een Nederlands verschijnsel - heeft dus nagenoeg geen internationale bekendheid/draagvlak 2) De tag is niet gedocumenteerd op de wiki 3) Het woord wordt verkeerd gebruikt - de waarden zijn geen toponiemen 4) Geen brede ondersteuning door editors/renderers 5) Het is gebruikt om andere, wel gedocumenteerde/ondersteunde tags te vervangen Ik zou graag willen dat de huidige voorkomens van toponym=* opgeruimd worden en wellicht de voorgaande tags (landuse, name, etc) teruggezet. Wat vinden jullie? Colin [1] http://wiki.openstreetmap.org/wiki/3dShapes/Landuse_import Ik heb die toponiem tag ook al een paar keer gezien, maar ik begrijp de gedachte erachter niet. Een toponiem is een naam die afgeleid is van de streek of van een topografisch verschijnsel. Amsterdam - Dam in de Amstel. Het is niet zo dat de naam van een bos per definitie een toponiem is. Ik zie ook niet in waarom deze tag gebruikt moet worden. Voor de naam van een feature in OSM kun je gewoon name= gebruiken. De toponym toelichting in [1] begrijp ik ook niet. Waarom kun je name= niet gebruiken op een groot gebied dat is opgedeeld in kleine stukken? Of is dat om er voor te zorgen dat voor de kleine stukken de naam niet gerenderd wordt? Los dat op met een relatie. toponym=forest is IMHO ook incorrect. Een bos is geen toponiem. De naam van een bos kan een toponiem zijn. Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Ik zal kort zijn, want het volledige antwoord ben ik kwijtgeraakt in de browser, omdat ik een 'ë' wilde intypen terwijl de numlock toets uitstond. De tag is door Lennard en mij geïntroduceerd, om de namen van de landuse-vlakken van AND te bewaren tijdens de 3dShapes import. De vlakken zelf zijn omgetagd, omdat je anders grote stukken dubbele landuse krijgt, wat niet wenselijk is. Het was de bedoeling om hier een goed voorstel voor te schrijven, maar vanwege tijdgebrek is dit er niet meer van gekomen. Er bestaat al rendering-support, aangezien de namen zelf worden weergegeven. Hier gaat het namelijk om. Het idee achter de toponym-tag zelf is om renderers een hint mee te geven van hoe de naam gerenderd kan worden. Het kan in theorie ook voor grote gebieden, zoals de Alpen worden gebruikt. Dat wil je niet allemaal met een relatie o.i.d. bijhouden. Zelfs de Veluwe niet ;) Verder betekent toponiem letterlijk plaatsnaam [1]. Het zegt niet iets over hoe de naam tot stand is gekomen. Groeten, Frank [1] http://en.wikipedia.org/wiki/Toponymy ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Wat ook meespeelde in onze overweging is dat het gebruik van de landuse-tag een zootje is geworden. Het beschrijft zowel de functie (landuse=park) als wat er in het terrein te vinden is (landuse=forst). Er is ook een grote overlap met de natural-tag. Van natural=wood vs. landuse=forest kan ik het onderscheid nog wel begrijpen (want niet-beheerd / wel beheerd), maar waarom wordt dan wel natural=water gebruikt in een land zoals Nederland, waar het meeste water haar natuurlijke karakter al lang verloren heeft (of zelfs nooit gehad heeft)? Misschien kan een eventueel toponiem-voorstel, mocht dat ooit toch van de grond komen, worden aangevuld met een tagging-voorstel wat een duidelijk onderscheid maakt tussen functie en fysiek voorkomen. Het is lastig om hierin eenduidigheid te krijgen. Bijv. Julianapark: toponiem: name=Julianapark functioneel: function=park landgebruik (huidige tagging): meerdere vlakken met landuse=forest; landuse=grass; natural=water Hier kan function=park en name=Julianapark prima worden gecombineerd. Dit komt goed over met ons oorspronkelijke idee. Alpen: toponiem: name=Alps; hoe aangeven dat dit een gebergte is? (dus: toponym=mountain_range) functioneel: n.v.t.? De Alpen zijn er; het is niet door mensen bepaald dat de Alpen moeten komen waar ze nu zijn. Wel zijn er binnen de Alpen regionaal en lokaal vele gebieden met allerlei soorten
Re: [OSM-talk-nl] Toponym
Citeren Maarten Deen md...@xs4all.nl: On 2012-03-23 10:52, Frank Steggink wrote: Citeren Frank Steggink stegg...@steggink.org: Citeren Maarten Deen md...@xs4all.nl: On 2012-03-23 08:56, Colin Smale wrote: Op dit moment wordt op een paar duizend plekken de tag toponym gebruikt, waarvan bij allemaal in Nederland. Maar wat ik zie in de waarden zijn volgens mij helemaal geen toponiemen! park, forest etc. zijn geen toponiemen maar voorbeelden van landgebruik/dekking. Julianapark en Zwarte Woud zouden wel toponiemen zijn. Of begrijp ik het woord toponym verkeerd? Ik zag dat er in feb 2010 een discussie was over detail omgeving oldenzaal waarin melding werd gemaakt van een nieuw voorstel voor toponiem-gebruik, en er is ook een Nederlandse Wiki-pagina [1] die daar heel kort iets over zegt waarin de basis wordt gelegd voor dit (IMHO) misbruik van de term. T.a.v. de toponym-tag heb ik de volgende constateringen: 1) Het is bijna uitsluitend een Nederlands verschijnsel - heeft dus nagenoeg geen internationale bekendheid/draagvlak 2) De tag is niet gedocumenteerd op de wiki 3) Het woord wordt verkeerd gebruikt - de waarden zijn geen toponiemen 4) Geen brede ondersteuning door editors/renderers 5) Het is gebruikt om andere, wel gedocumenteerde/ondersteunde tags te vervangen Ik zou graag willen dat de huidige voorkomens van toponym=* opgeruimd worden en wellicht de voorgaande tags (landuse, name, etc) teruggezet. Wat vinden jullie? Colin [1] http://wiki.openstreetmap.org/wiki/3dShapes/Landuse_import Ik heb die toponiem tag ook al een paar keer gezien, maar ik begrijp de gedachte erachter niet. Een toponiem is een naam die afgeleid is van de streek of van een topografisch verschijnsel. Amsterdam - Dam in de Amstel. Het is niet zo dat de naam van een bos per definitie een toponiem is. Ik zie ook niet in waarom deze tag gebruikt moet worden. Voor de naam van een feature in OSM kun je gewoon name= gebruiken. De toponym toelichting in [1] begrijp ik ook niet. Waarom kun je name= niet gebruiken op een groot gebied dat is opgedeeld in kleine stukken? Of is dat om er voor te zorgen dat voor de kleine stukken de naam niet gerenderd wordt? Los dat op met een relatie. toponym=forest is IMHO ook incorrect. Een bos is geen toponiem. De naam van een bos kan een toponiem zijn. Ik zal kort zijn, want het volledige antwoord ben ik kwijtgeraakt in de browser, omdat ik een 'ë' wilde intypen terwijl de numlock toets uitstond. De tag is door Lennard en mij geïntroduceerd, om de namen van de landuse-vlakken van AND te bewaren tijdens de 3dShapes import. De vlakken zelf zijn omgetagd, omdat je anders grote stukken dubbele landuse krijgt, wat niet wenselijk is. Kon je dan niet beter name:AND gebruiken? Je hebt nu een verwarrende tag geintroduceerd. Verder betekent toponiem letterlijk plaatsnaam [1]. Het zegt niet iets over hoe de naam tot stand is gekomen. Ja, de griekse vertaling van topo-niem is plaats-naam. Maar een toponiem is een naam die is afgeleid van de plaats/omgeving/omstandigheden van waar het object zich bevindt of hoe het er uitziet. Zoals ik al eerder heb gezegd: het is niet zo dat een plaatsnaam automatisch een toponiem is, alhoewel het dat natuurlijk meestal wel is. Alpen: toponiem: name=Alps; hoe aangeven dat dit een gebergte is? (dus: toponym=mountain_range) mountain_range is geen toponiem. mountain_range is een omschrijving van datgene wat er is. Alpen is juist het toponiem, want Alpen is afgeleid van het Latijnse woord voor wit (de definitie van een toponiem: een naam die is afgeleid van datgeen wat er is). Dan zou het eerder moeten zijn: toponym=Alps, name=mountain_range. Of description=mountain_range. IMHO is de tag toponym in OSM overbodig. Want als de naam een toponiem is dan is toponym gelijk aan name. Als de naam geen toponiem is dan heeft het object geen toponiem. Het gebruik van toponym=park of toponym=forest is helemaal onjuist. Volgens mij is voor de soort begroeiing de landuse tag en voor het gebruik kun je o.a. leisure gebruiken (landuse=grass, leisure=park). Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl OK, vervang dan 'toponym' maar door 'description'. Zolang het maar geen 'landuse' / 'leisure' / etc. wordt, of is dit volgens jou taggen voor de renderer? Name:AND lost niks op. Het ging er ons hoofdzakelijk om de landuse-tag van de shape af te halen, zodat je dan geen dubbele vlakken krijgt. Dat zou helemaal niet acceptabel zijn geweest voor de 3dShapes import. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Toponym
Citeren Maarten Deen md...@xs4all.nl: Dan gebruik je landuse:AND. Ik dacht dat je de name-tag van AND wilde bewaren. Achteraf gezien was dat beter geweest. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Toponym
Citeren Colin Smale colin.sm...@xs4all.nl: On 23/03/2012 11:52, Lennard wrote: Niet omdat het kan, maar omdat het wellicht zou moeten; met beleid natuurlijk en niet rücksichtslos. Hoe veel van de 2000+ voorkomens van toponym=* in NL zijn vergelijkbaar met wat er onlangs met het Julianapark (Utrecht) [1] gebeurde? Hierbij is leisure=park vervangen met toponym=park met het gevolg dat het niet langer als park herkenbaar was. Aan de begroeiing, weergegeven door landuse=forest + landuse=grass, is wel op te maken dat het een park in. Toen ik afgelopen week hier bezig was, heb ik de tag leisure=park vervangen door toponym=park. Dat er nog een discussie loopt over ontdubbeling van vlakken n.a.v. de 3dshapes import is een ding, maar kunnen wij alsjeblieft onze 1418 forests, 597 parken, 44 cemeteries (zie tagwatch [2]) etc etc terugkrijgen? Dan krijg je overal in Nederland de situatie zoals nu met het Julianapark. In bijna alle gevallen is er sprake van dubbel landuse, anders was er uberhaupt voor ons geen reden om de toponym-tag in te zetten. Is dat wat jou voor ogen staat? Wellicht kan de styling worden aangepast voor functionele tags (zoals leisure). Belangrijk om te weten is dat de informatie niet verloren is, in afwachting van een beter voorstel. Ik ben het wel met je eens dat de huidige situatie niet ideaal is en dat er een betere oplossing moet komen. V.w.b. mijn aanpassingen van afgelopen week [1]: ik hoop tenminste dat je akkoord gaat met de verwijdering van het park aan weerszijden en in de middenberm van de Einsteindreef en langs de rand van de N230. Verder heb ik toen de shape van Park de Gagel hersteld [2]. Dit had al de toponym-tag, maar was opgeknipt geraakt. Hier speelde nog een ander issue, namelijk dat er 3 3dShapes-vlakken [3] [4] [5] een naam hadden gekregen. Niet geheel willekeurig, maar wel zodat de naam op representatieve plekken in het park worden gerenderd. Dat is de light-variant van het taggen van alle shapes in een bepaald gebied met een naam. Kortom, er genoeg aanleiding om eens na te gaan denken voor een betere tagging om gebieden een naam te geven, maar waarbij wel recht wordt gedaan aan de functie en het fysieke voorkomen. V.w.b. het landcover-voorstel wat door G.J. wordt genoemd: is daar de laatste tijd nog over gepraat? Groeten, Frank [1] http://www.openstreetmap.org/browse/changeset/11043851 [2] http://www.openstreetmap.org/browse/way/143448708 [3] http://www.openstreetmap.org/browse/way/72107784 [4] http://www.openstreetmap.org/browse/way/72107938 [5] http://www.openstreetmap.org/browse/way/72110476 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Uitsnede OSM van Amsterdam
On 23-3-2012 14:31, Steven M. Ottens wrote: Hoi allemaal, WhereCampEU (http://wherecamp.eu) komt het weekend voor Koninginnedag naar Amsterdam. Voor de bezoekers wil ik een leuke online en offline kaart *) maken met uitleg wat waar is etc. is er ergens een recente uitsnede van Amsterdam te vinden? Bij voorkeur alleen van het gebied binnen de A10, of kan iemand dat in een handomdraai doen? Alvast bedankt Steven *) iets met tilemill, mbtiles en apps voor mobieltjes, ideeën daarvoor zijn ook welkom. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Hoi Steven, Kijk eens hier: http://metro.teczno.com/#amsterdam Het is wel een stuk groter dan de stad zelf, maar beter te hanteren dan de planet-dump of zelfs de benelux-dump. Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Toponym
On 23-3-2012 16:54, Colin Smale wrote: Dan krijg je overal in Nederland de situatie zoals nu met het Julianapark. In bijna alle gevallen is er sprake van dubbel landuse, anders was er uberhaupt voor ons geen reden om de toponym-tag in te zetten. Is dat wat jou voor ogen staat? Wellicht kan de styling worden aangepast voor functionele tags (zoals leisure). Belangrijk om te weten is dat de informatie niet verloren is, in afwachting van een beter voorstel. Ik ben het wel met je eens dat de huidige situatie niet ideaal is en dat er een betere oplossing moet komen. De informatie is wel uit het zicht verdwenen omdat de oorspronkelijke tags verwijderd zijn. Iedereen mag nieuwe tags toevoegen - dit is inherent aan het open karakter van OSM. Maar het verwijderen van bestaande, breed geaccepteerde tags kan niet zomaar. En het misbruiken van woorden zoals nu gebeurt met toponym is zonder meer iets wat vermeden moet worden. Ik was in de veronderstelling dat dat hier geen probleem was, omdat: a) het evident is dat het gebied een park is, door de geïmporteerde landuse. b) de informatie an sich niet verloren is gegaan. Niet alle informatie in de DB wordt op de kaart gerenderd. Hoe vaak wil je dat ik nog sorry moet zeggen, omdat wij de toponym-tags hebben gebruikt als placeholder? Ik heb je nu wel begrepen... Verder waren we al meer dan 2 jaar geleden begonnen met de import van 3dShapes data en is deze al een tijd afgerond (op 2 kleine plukjes na). Blijkbaar was de toponym-tag al die tijd geen issue, maar omdat ik toevallig een paar dagen geleden het waagde om het Julianapark aan te passen, nu in een keer wel? V.w.b. mijn aanpassingen van afgelopen week [1]: ik hoop tenminste dat je akkoord gaat met de verwijdering van het park aan weerszijden en in de middenberm van de Einsteindreef en langs de rand van de N230. Dat lijkt mij geen probleem! Een park is pas een park als de gemeente (of ander beheerorgaan) het zo noemt, lijkt mij. Verder heb ik toen de shape van Park de Gagel hersteld [2]. Dit had al de toponym-tag, maar was opgeknipt geraakt. Hier speelde nog een ander issue, namelijk dat er 3 3dShapes-vlakken [3] [4] [5] een naam hadden gekregen. Niet geheel willekeurig, maar wel zodat de naam op representatieve plekken in het park worden gerenderd. Dat is de light-variant van het taggen van alle shapes in een bepaald gebied met een naam. Jouw beeld van de grens van Park de Gagel wijkt wel sterk af van het beeld van Gemeente Utrecht... zie pagina 38 (inzoomen vereist!!) van http://www.utrecht.nl/images/Stadswerken/Parken/beheerplan180308.pdf Mijn beeld is een samenvoeging van 2 ways met toponym=park; area=yes, inclusief de namen die op 3 grasvelden stonden binnen het park. Verder heb ik me niet in de officiële omvang van het betreffende park verdiept. Is dat een vereiste voordat er überhaupt een verandering gemaakt mag worden? Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] In het licht van de toponym-thread
Beste lijstgenoten, Hieronder staat een mail die ik naar talk-nl heb gestuurd n.a.v. de BAG-discussie, met de ervaring van de 3dShapes import in het achterhoofd. Zie ook hier: [1] Ik ga hier even doorheen lopen, omdat het de toponym-discussie raakt. Verder had ik verwacht dat onderstaande mail de nodige discussie zou opleveren, maar de respons was 0,0. On 1-2-2012 20:52, Frank Steggink wrote: Voordat het import-virus losbarst: wees je er wel van bewust wat voor klus dit is! Dit kan ik niet genoeg benadrukken. Elke import is uniek. De BAG-import heeft meer voeten in de aarde dan bijv. de 3dShapes import. Dit om de volgende redenen: * Vervanging bestaande data: Ten tijde van de 3dShapes import was NL redelijk blanco op het gebied van gebouwen en landgebruik. (De AND-landuse was van lage kwaliteit, dus die kon worden verwijderd.) Nu staat NL vol met gebouwen uit de 3dShapes. Voor een deel zijn deze ook bewerkt / verrijkt met andere data. Je kunt geen import doen zonder hier een goede oplossing voor te verzinnen. In het geval de 3dShapes gebouwen niet gewijzigd zijn (version=1), zouden deze vervangen kunnen worden. Probeer dus eerst inzichtelijk te krijgen welke gebouwen wel problemen opleveren, bijv. omdat je tags moet omzetten. Ga eerst in conclaaf met andere OSM-ers die wijzigingen aan de gebouwen hebben aangebracht in het gebied waarvan je de BAG wil importeren. Wat mijn opmerking over de AND-landuse betreft: ik sta hier nog steeds achter. Shapes met een naam zijn omgetagd. Redundante shapes zijn verwijderd. Dit kunnen ook vlakken met alleen een tag leisure=park zijn geweest. Oeps, wat nu? Er geldt nog steeds dat er landuse voor in de plaats is gekomen, dus op de kaart is het nog steeds als zodanig zichtbaar. Verder is het maar de vraag of de situatie in de AND-data juist was en of de gekozen tagging voor de AND-import juist was. * Verantwoordelijkheid: als je aan een import begint, heb je je te houden aan de import guidelines. Zie hier: http://wiki.openstreetmap.org/wiki/Import_guidelines . Als jij zelf BAG-data wil importeren, heb jij je _zelf_ hier aan te houden, omdat de import onder _jouw_ account zal plaatsvinden. Je bent dus ook verantwoordelijk voor eventuele troep die je achterlaat. Natuurlijk ga je die ook zelf opruimen ;) De rest van de community zit hier niet op te wachten. Vraag je eerst af of je bereid bent je hieraan te committen. Zie ook het volgende punt. Of je het er mee eens bent of niet: dit hebben wij ook gedaan met de 3dShapes import. Wel naar onze eigen inzichten. Gezien het feit dat er weinig feedback was, hadden wij geen reden om aan te nemen dat wij er een zootje van maakten. Alhoewel ik op voorhand mij van dit punt bewust was, heb ik wel in de loop van het proces ervaren hoe belangrijk dit is. Een andere conclusie is dat je het nooit goed genoeg doet en niet iedereen 100% tevreden kunt stellen, zoals de toponym-thread bewijst. * Updates: al aangestipt. Zeker zinvol om over na te denken, maar het probleem hier is dat dit niet af te dwingen is. Iemand kan ergens de BAG importeren en plechtig beloven zich te committen aan updates, maar als hij een andere hobby heeft gevonden, zijn er ook geen updates meer. N.v.t. voor de 3dShapes, aangezien die eenmalig was. Technisch gezien zou je met Top10NL 3dShapes kunnen updaten, maar daar was in 2009/2010 totaal geen zicht op. * Nut: wat is de toegevoegde waarde van de BAG in OSM? De adressen ontbreken in OSM, wat handig is voor routing, e.d., maar er zijn al wel gebouwen. IMO zijn deze van voldoende kwaliteit voor de meeste toepassingen van OSM. Ik wil natuurlijk in mijn gebied wel de best beschikbare data, maar ik weet ook al dat, als ik een mooie kaart van NL ga maken, ik de BAG data wel uit de originele bron ga betrekken en niet uit OSM. Dit omdat de BAG zelf de beste bron is. Wie weet wat er met de OSM data is gerommeld is en wat de actualiteit is? Zelfs al loopt OSM voor (wat heel goed mogelijk is), je kunt niemand binnen OSM aanspreken als de situatie niet klopt. Het standaardantwoord: pas het lekker zelf aan. In de GIS-wereld loopt al enige jaren de discussie tussen authoritive data vs. crowdsourced data, wat hierop betrekking heeft. Het is evident wat het nut van de 3dShapes import is. Daarom kozen we in de 1e plaats voor deze import. Nu is ons land al voorzien van landuse data, en hoeven we niet als een gek van Bing te tracen (waar actualiteit ook een probleem is). Het bovenstaande punt geldt trouwens ook voor de landuse. Ja, in die zin heb ik maanden vrije tijd voor niks besteed, maar toen was ook niet bekend dat de Top10NL open data zou worden. Mijn handen jeuken totaal niet om Top10NL in OSM te laden. Hooguit om de 3dShapes data ten dele te verrijken, om fouten met de classificaties ongedaan te maken. Bij de 3dShapes-import is i.i.g. hier wel zoveel mogelijk rekening gehouden en tijd ingestoken. Een ander voorbeeld van de moeite die wij erin hebben
Re: [OSM-talk-nl] Postcodes semi-automatisch toevoegen aan adrespunten
On 1-2-2012 10:44, Ruud den Blanken wrote: Vorig jaar heb ik OSM rondom Gorinchem aangepast door panden en adressen uit de BAG toe te voegen. Ik had ook de beschikking over postcodes maar die mochten vanwege licentiebezwaren nog niet worden toegevoegd. Vandaag, per 1 februari 2012, mag het wel. De vraag is nu hoe ik dit het beste kan aanpakken. Alle adrespunten die ik wil uitbreiden met een addr:postcode tag, hebben nu in principe al een tag bag:vbo_id. Ik kan een lijst genereren van alle verblijfsobject_id's met bijbehorende postcodes. Liefst zou ik hieruit een script met update-query's genereren die ik kan loslaten op OSM. Ik maak voornamelijk gebruik van JOSM en kon geen plugins vinden die in dit soort functionaliteit voorzien. Waarschijnlijk moet ik dit vanuit een andere invalshoek benaderen. Iemand hints hoe dit aan te pakken? Met vriendelijke groet, Ruud den Blanken Gorinchem Hoi Ruud, Zoals je weet, kun je niet zomaar een script met update-queries uitvoeren tegen de OSM-database aan ;) Je moet de adrespunten downloaden als OSM file, bewerken en vervolgens uploaden. Ik geloof niet dat er tools beschikbaar zijn om een join uit te voeren van OSM-data met een externe databron. Dit zou je moeten scripten. Voor upload met JOSM kun je gebruik maken van het eigen file formaat: http://wiki.openstreetmap.org/wiki/JOSM_file_format . Dit lijkt erg op het standaard OSM XML-formaat. D.m.v. een action-attribuut kun je aangeven wat er met de data moet gebeuren. Voorbeeldje: node id='1608043892' action='modify' timestamp='2012-01-28T00:16:32Z' uid='210260' user='jotpe' visible='true' version='1' changeset='10517630' lat='52.3024097' lon='7.1756024' tag k='bag:vbo_id' v='abcdef' / tag k='addr:housenumber' v='yyy' / tag k='addr:street' v='xxx' / tag k='addr:postcode' v='zzz' / /node De attributen id, timestamp, uid, user, visible, version, changeset, lat en lot zijn standaard-attributen. Deze waren al aanwezig in de download. Het action-attribuut geeft aan dat de betreffende node moet worden geupdate. De tags geven aan welke tags de nieuwe versie moet hebben. Je kunt aan de tags niet zien welke nieuw is, dus je moet gewoon die van jou toevoegen. BELANGRIJK: aangezien je bestaande data wijzigt, zorg ervoor dat je de bewerkingstijd zo kort mogelijk houdt! Het heeft dus de voorkeur om kleine gebieden tegelijk te updaten, omdat in theorie de kans aanwezig is dat anderen tussentijds de data bewerken. Je kunt de database immers niet freezen. Dit heeft als gevolg dat jij conflicten moet oplossen indien nodig. Dat is zonde van de tijd. Let er dan ook op dat je na een upload eerst nieuwe data downloadt, om eventuele wijzigingen mee te pakken. Mogelijk is in jouw geval FME een optie. Ik ben niet bekend met de OSM-writer, maar als je zelf het action-attribuut in het node-element weet te krijgen i.p.v. als tag, dan zou het wel eens kunnen werken. De andere attributen moeten dan niet wijzigen. Als dit klaar is, zou je de wijzigingen met JOSM kunnen uploaden. Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Postcodes semi-automatisch toevoegen aan adrespunten
Voordat het import-virus losbarst: wees je er wel van bewust wat voor klus dit is! Dit kan ik niet genoeg benadrukken. Elke import is uniek. De BAG-import heeft meer voeten in de aarde dan bijv. de 3dShapes import. Dit om de volgende redenen: * Vervanging bestaande data: Ten tijde van de 3dShapes import was NL redelijk blanco op het gebied van gebouwen en landgebruik. (De AND-landuse was van lage kwaliteit, dus die kon worden verwijderd.) Nu staat NL vol met gebouwen uit de 3dShapes. Voor een deel zijn deze ook bewerkt / verrijkt met andere data. Je kunt geen import doen zonder hier een goede oplossing voor te verzinnen. In het geval de 3dShapes gebouwen niet gewijzigd zijn (version=1), zouden deze vervangen kunnen worden. Probeer dus eerst inzichtelijk te krijgen welke gebouwen wel problemen opleveren, bijv. omdat je tags moet omzetten. Ga eerst in conclaaf met andere OSM-ers die wijzigingen aan de gebouwen hebben aangebracht in het gebied waarvan je de BAG wil importeren. * Verantwoordelijkheid: als je aan een import begint, heb je je te houden aan de import guidelines. Zie hier: http://wiki.openstreetmap.org/wiki/Import_guidelines . Als jij zelf BAG-data wil importeren, heb jij je _zelf_ hier aan te houden, omdat de import onder _jouw_ account zal plaatsvinden. Je bent dus ook verantwoordelijk voor eventuele troep die je achterlaat. Natuurlijk ga je die ook zelf opruimen ;) De rest van de community zit hier niet op te wachten. Vraag je eerst af of je bereid bent je hieraan te committen. Zie ook het volgende punt. * Updates: al aangestipt. Zeker zinvol om over na te denken, maar het probleem hier is dat dit niet af te dwingen is. Iemand kan ergens de BAG importeren en plechtig beloven zich te committen aan updates, maar als hij een andere hobby heeft gevonden, zijn er ook geen updates meer. * Nut: wat is de toegevoegde waarde van de BAG in OSM? De adressen ontbreken in OSM, wat handig is voor routing, e.d., maar er zijn al wel gebouwen. IMO zijn deze van voldoende kwaliteit voor de meeste toepassingen van OSM. Ik wil natuurlijk in mijn gebied wel de best beschikbare data, maar ik weet ook al dat, als ik een mooie kaart van NL ga maken, ik de BAG data wel uit de originele bron ga betrekken en niet uit OSM. Dit omdat de BAG zelf de beste bron is. Wie weet wat er met de OSM data is gerommeld is en wat de actualiteit is? Zelfs al loopt OSM voor (wat heel goed mogelijk is), je kunt niemand binnen OSM aanspreken als de situatie niet klopt. Het standaardantwoord: pas het lekker zelf aan. In de GIS-wereld loopt al enige jaren de discussie tussen authoritive data vs. crowdsourced data, wat hierop betrekking heeft. Het bovenstaande punt geldt trouwens ook voor de landuse. Ja, in die zin heb ik maanden vrije tijd voor niks besteed, maar toen was ook niet bekend dat de Top10NL open data zou worden. Mijn handen jeuken totaal niet om Top10NL in OSM te laden. Hooguit om de 3dShapes data ten dele te verrijken, om fouten met de classificaties ongedaan te maken. Bij de 3dShapes-import is i.i.g. hier wel zoveel mogelijk rekening gehouden en tijd ingestoken. * Afhankelijkheid van anderen: er wordt wel geroepen dat er moet worden nagedacht over zaken of dat er iets beschikbaar moet komen, maar wie gaat daadwerkelijk tijd en serverruimte vrij maken om dit ook te regelen? Is het reëel om te verwachten dat anderen dit klusje voor jou gaan klaren? We zijn allemaal vrijwilliger en 99,9% van ons heeft ook andere dingen te doen. Zelf ben ik er nog niet uit of ik mijzelf wil committen aan de BAG. Zoals gezegd wil ik in de gebieden die mijn meeste interesse hebben wel de beste data, maar aan de andere kant zie ik op tegen het integreren met de bestaande data en het blijvend actualiseren. Ik kan alleen constateren dat de behoefte om delen van de BAG te importeren eerder afneemt dan toeneemt. Dit zeg ik zowel met de OSM- als met de werk-pet op. Zo, dat was het wel voor deze keer :) Groeten, Frank On 1-2-2012 17:44, Floris Looijesteijn wrote: Ik wil dit ook wel doen voor Haarlem maar laten we in ieder geval een procedure bedenken voor hoe we omgaan met updates. Waar TS dus nu tegenaan loopt zou je ook als update kunnen zien. Groet, Floris 2012/2/1 Robert Elsenaarrob...@elsenaar.info: +1 Met vriendelijke groeten, Robert Elsenaar (Verzonden vanaf Mobile) drekd...@drek.nl schreef: Op 01-02-12 11:49, Floris Looijesteijn schreef: 2012/2/1 Ruud den Blankenruud.den.blan...@gmail.com: Vorig jaar heb ik OSM rondom Gorinchem aangepast door panden en adressen uit de BAG toe te voegen. Maar die import ziet er best mooi uit, is dat ergens gedocumenteerd? Die import ziet er zeker mooi uit. Ik wil de BAG-gegevens ook toevoegen in mijn woonplaats Woudenberg, maar ik weet eerlijk gezegd nog niet precies hoe. Ik ben dat nu aan het uitzoeken hoe dat werkt. Een gedocumenteerde import zou dus zeer van pas kunnen komen. :-) Groeten, André
Re: [OSM-talk-nl] Leidsche Rijntunnel (A2 Utrecht) wordt eindelijk in gebruik genomen
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
[OSM-talk-nl] Leidsche Rijntunnel (A2 Utrecht) wordt eindelijk in gebruik genomen
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
Re: [OSM-talk-nl] NLExtract project
On 23-1-2012 21:27, Michiel Faber wrote: Just van den Broecke schreef op ma 23-01-2012 om 10:33 [+0100]: Dit zijn o.a. de gotchas waar ik in een eerdere mail op doelde. En mogelijk zijn er die ik nog niet ken. groeten, Just Hallo, Ik spui hier zomaar wat vragen die in mij opkomen omtrent de top10. Dit zijn zo maar dingen die in mij opkomen. Wellicht al bij jullie opgekomen, niet relevant of al in overleg met het kadaster. Weet het Kadaster van deze gotchas? Zijn ze bewust er in gebracht? Hoe gaan zij er mee om? Wellicht een idee om er met hun over te praten om de brondata al in een beter formaat (aangeleverd) te krijgen of hun manier van werken te bekijken? Succes, Michiel Michiel, De meeste gotcha's zijn inherent aan het datamodel van Top10NL, dus ze zijn bewust ingebracht. Dit is gebaseerd op GML (geography markup language). Op basis hiervan is door Geonovum NEN3610 ontwikkeld en geïmplementeerd in GML (via een XML Schema-definitie). Dit heeft als doel uitwisseling van ruimtelijke data in Nederland. Dit model is behoorlijk complex. Top10NL is weer op basis van NEN3610 ontwikkeld. Volgens mij is dit alleen door het Kadaster gedaan. NEN3610 biedt al de mogelijkheid om meerdere geometrieën aan een object te koppelen (bijv. oppervlakte en hartlijn van een weg), of om meerdere attributen met dezelfde naam toe te voegen (bijv. wegnummers: een weg kan meerdere wegnummers hebben). Het doel is om de informatie zo compleet mogelijk op te slaan en uit te wisselen. Het is aan de gebruikers hiervan om te bepalen welke data wel of niet getoond wordt. Dit heeft als consequentie dat de tooling aan behoorlijke eisen moet voldoen. ogr2ogr komt een heel eind, maar niet overal is een oplossing voor. Bijv. de meerdere geometrieen per object: hiervoor is dus de splitsings-stap nodig. Uitlevering in een ander formaat lost het probleem niet 1-2-3 op. Bijv. Shape is te beperkt om alle informatie ongeschonden door te laten. De data zoals die door het Kadaster wordt uitgeleverd is ook geen eindproduct waar een willekeurige gebruiker iets mee kan. Daarvoor moet er nog een bewerkingsslag overheen. De reden dat het NLExtract project is opgestart is juist om deze bewerkingsslag te maken en afgeleide producten te genereren, bijv. database-dumps voor PostgreSQL/PostGIS en Oracle. Dit is geen verantwoordelijkheid van het Kadaster. De markt kan het prima oplossen. (Het Kadaster levert wel de data in FGDB uit, maar waarschijnlijk komt dat omdat dit een tussenproduct van hun eigen werkproces is.) O.a. op LinkedIn in de NL OpenData groep is hierover discussie gevoerd. Andere gotcha's zijn niet bewust: * Afkappen van velden: dit is iets wat ogr2ogr blijkt te doen. Hier is omheen te werken, door bijv. de GFS-bestanden te editen. * Niet-validerende GML: ik heb begrepen dat het Kadaster hier ondertussen van op de hoogte is. In april zou een goede versie moeten komen. (Kan geen linkje vinden.) * Sommige objecten zijn dubbel als je alles importeert. Dit komt omdat ze over de bladgrenzen heen liggen. Dat zullen we met de hand moeten oplossen, tenzij het Kadaster een set landsdekkende GML's gaat maken waar geen dubbelingen in voorkomen. Voor de rest moeten we zien waar het schip strandt ;) Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] NLExtract project
On 23-1-2012 21:58, Frank Steggink wrote: Michiel, De meeste gotcha's zijn inherent aan het datamodel van Top10NL, dus ze zijn bewust ingebracht. Dit is gebaseerd op GML (geography markup language). Op basis hiervan is door Geonovum NEN3610 ontwikkeld en geïmplementeerd in GML (via een XML Schema-definitie). Dit heeft als doel uitwisseling van ruimtelijke data in Nederland. Dit model is behoorlijk complex. Top10NL is weer op basis van NEN3610 ontwikkeld. Volgens mij is dit alleen door het Kadaster gedaan. NEN3610 biedt al de mogelijkheid om meerdere geometrieën aan een object te koppelen (bijv. oppervlakte en hartlijn van een weg), of om meerdere attributen met dezelfde naam toe te voegen (bijv. wegnummers: een weg kan meerdere wegnummers hebben). Het doel is om de informatie zo compleet mogelijk op te slaan en uit te wisselen. Het is aan de gebruikers hiervan om te bepalen welke data wel of niet getoond wordt. Dit heeft als consequentie dat de tooling aan behoorlijke eisen moet voldoen. ogr2ogr komt een heel eind, maar niet overal is een oplossing voor. Bijv. de meerdere geometrieen per object: hiervoor is dus de splitsings-stap nodig. Uitlevering in een ander formaat lost het probleem niet 1-2-3 op. Bijv. Shape is te beperkt om alle informatie ongeschonden door te laten. De data zoals die door het Kadaster wordt uitgeleverd is ook geen eindproduct waar een willekeurige gebruiker iets mee kan. Daarvoor moet er nog een bewerkingsslag overheen. De reden dat het NLExtract project is opgestart is juist om deze bewerkingsslag te maken en afgeleide producten te genereren, bijv. database-dumps voor PostgreSQL/PostGIS en Oracle. Dit is geen verantwoordelijkheid van het Kadaster. De markt kan het prima oplossen. (Het Kadaster levert wel de data in FGDB uit, maar waarschijnlijk komt dat omdat dit een tussenproduct van hun eigen werkproces is.) O.a. op LinkedIn in de NL OpenData groep is hierover discussie gevoerd. Andere gotcha's zijn niet bewust: * Afkappen van velden: dit is iets wat ogr2ogr blijkt te doen. Hier is omheen te werken, door bijv. de GFS-bestanden te editen. * Niet-validerende GML: ik heb begrepen dat het Kadaster hier ondertussen van op de hoogte is. In april zou een goede versie moeten komen. (Kan geen linkje vinden.) * Sommige objecten zijn dubbel als je alles importeert. Dit komt omdat ze over de bladgrenzen heen liggen. Dat zullen we met de hand moeten oplossen, tenzij het Kadaster een set landsdekkende GML's gaat maken waar geen dubbelingen in voorkomen. Voor de rest moeten we zien waar het schip strandt ;) Een andere gotcha waar ik bang voor was, nl. meertaligheid, zit ook in Top10NL. Zie bestand 06west.gml. top10nl:GeografischGebied gml:id=nl.top10nl.103078931 nen3610:identificatieNL.TOP10NL.103078931/nen3610:identificatie nen3610:objectBeginTijd2008-11-24T00:00:00/nen3610:objectBeginTijdnen3610:versieBeginTijd2008-11-24T00:00:00/nen3610:versieBeginTijd top10nl:naam xml:lang=nlLeeuwarden/top10nl:naam top10nl:naam xml:lang=fyLjouwert/top10nl:naam top10nl:typeGeografischGebied plaats, bewoond oord/top10nl:typeGeografischGebied top10nl:labelPuntgml:Point srsName='urn:opengis:def:crs:EPSG::28992'gml:pos srsDimension=2182596.785 579147.489/gml:pos/gml:Point/top10nl:labelPunt top10nl:brontypetop10vector/top10nl:brontype top10nl:bronbeschrijvingTOP10vector 2004/top10nl:bronbeschrijving top10nl:bronactualiteit2004-01-01/top10nl:bronactualiteit top10nl:bronnauwkeurigheid2/top10nl:bronnauwkeurigheid top10nl:dimensie2D/top10nl:dimensie /top10nl:GeografischGebied De naam Leeuwarden komt ook in het Fries voor, Ljouwert (met xml:lang=fy). Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] PDOK deels openbaar
Sorry voor de crosspost en het is laat, maar ik heb eigenlijk op beide lijsten het nieuws gemist dat een aantal open-data datasets vanaf vandaag via PDOK op te vragen zijn. Just attendeerde me gisteren hierop. Nieuws van Geonovum: http://www.geonovum.nl/nieuws/pdok/open-data-publieke-dienstverlening-op-kaart Demoviewer: http://nieuwsinkaart.nl/pdok/ Info voor het fair use gebruik: http://www.geonovum.nl/dienstenniveau/PDOK-Fair-Use Deze service wordt as is ter beschikkingg esteld. Misschien is het een idee voor een nieuw projectje om op de osgeo.nl wiki-site documentatie te zetten? Het is voor mij nu te laat om nog het veld op te rennen om te voetballen :) Groeten, Frank Steggink ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fwd: [OpenStreetMap] ODBL licentie wijziging OSM
On 21-1-2012 11:39, Pim Clotscher wrote: Ik ben nieuw op deze mailinglijst, maar al geruime tijd actief op het forum en als mapper voor OSM.Mijn overtuiging is altijd geweest dat het forum het geijkte medium was (is??) om de mappers te bereiken en ook om daar de discussie te voeren over o.a. de licentie-wijziging. Ben benieuwd hoe dat dan gaat via deze lijst die me aangeraden is nadat ik iemand een PB had gestuurd met een uitnodiging om akkoord te gaan met ODbL (sommigen vatten zoiets op als spam...) :-) . Pim On 21-1-2012 0:57, Maarten Deen wrote: Op 21-01-12 00:13, Cartinus schreef: Als je de afzenders van deze berichtjes werkelijk wilt bereiken dan kun je dat beter doen op een plek waar ze het lezen: het forum. Is er eigenlijk een tweedeling? Zij de het forum gebruiken en zij die de mailinglijst gebruiken? Ik gebruik het forum eigenlijk niet. Ik zou nog niet eens weten waar het is. En waarom zou ik aannemen dat de afzenders van die berichten wel op het forum zitten maar niet op de mailinglijst? Is dat een ander soort mapper die daar zit? Er is geen geijkt medium om mappers te bereiken. Zowel het forum als de mailinglijst zijn plekken waar discussies gevoerd worden. De een voert liever discussie in een browser, terwijl de ander dat liever via zijn mailclient doet. Ikzelf vind daar niks mis mee. OpenStreetMap is niets meer dan een project waar veel mensen zich mee verbonden voelen, waardoor ook een heel ecosysteem aan discussieplekken (mailinglijsten, fora, wiki, blogs, irc) is ontstaan, naast het ecosysteem van software. Er is wel een groep mensen die zich heeft opgeworpen om het officiële orgaan van OSM te zijn (de OSMF), maar zelfs deze organisatie wordt door sommigen niet als zodanig erkend. Dit alles maakt het lastig om goed op de hoogte te blijven van alle gebeurtenissen. Voor velen is dat ook niet te doen. Daarvoor is het project veel te groot geworden (waar ik op zich blij om ben :) ). Maarten, het forum bestaat al bijna 5 jaar. Hier is de link: http://forum.openstreetmap.org/viewforum.php?id=12 , ook te bereiken via forum.openstreetmap.nl . Ik denk niet dat er sprake is van een tweedeling, maar ik heb wel de indruk dat degenen die op het forum zitten meer zijn geinteresseerd in het gebruik van OSM en minder in de techniek. Ofwel, de Nederlandse OSM-community is twee keer zo groot dan je denkt :) Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Mappers en 'Kadaster geeft gigabytes aan data vrij'
On 6-1-2012 17:39, drek wrote: Hallo allemaal, Wat mij nog niet helemaal duidelijk is, is wat dit betekent voor de gebruikers. Ik heb diverse aanpassingen in de kaart gedaan en heb nog wat aanpassingen op mijn to-do-lijstje staan. Zijn deze aanpassingen nog wel nodig als er Kadaster-informatie gebruikt gaat worden? En wat gebeurt er met bestaande data? Groeten, André ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Hallo Andre, Voorlopig betekent dit helemaal niks voor de OSM-vrijwilligers. Er zijn geen grootscheepse plannen om Top10NL data te importeren in OSM. Voorlopig kan dat ook niet, omdat OSM binnenkort volledig overgaat op de ODbL. Vraag is of het Kadaster hiermee akkoord gaat. ODbL kent wel attribution (bronvermelding), maar de licentie zou in de toekomst kunnen veranderen. Mocht die toestemming er zijn, dan vind ik dat we hier heel hard over moeten nadenken of we dit wel willen. Het is nl. een rotklus, met een marginale toegevoegde waarde. De 3dShapes dataset die de afgelopen jaren is geïmporteerd, is een afgeleid product van Top10vector (de voorloper van Top10NL). Qua geometrie is er geen verbetering, maar qua classificatie zou die er wel kunnen zijn. Het is makkelijker om een hybride kaart te gebruiken (voor visualisatie, gebruik in de GPS, etc.), die zowel op OSM als op Top10NL is gebaseerd. Voor de BAG (Basisregistratie Adressen en Gebouwen), wat ook speelt, ligt dit iets genuanceerder. Ik was een paar maanden geleden wel voorstander van een import, maar ben hierover van gedachten aan het veranderen. Ondanks dat de BAG open data is, is het lastig om hieraan te komen. In theorie heb je een abonnement nodig, alhoewel het feit dat de BAG open data is, ook betekent dat het verder verspreid kan worden (tot 1 feb. a.s. nog m.u.v. postcodes). In OSM zitten al gebouwen, die voor het schaalniveau van OSM van voldoende kwaliteit zijn. (Dit geldt natuurlijk niet voor nieuwbouw.) Van alleen de adressen is de toegevoegde waarde veel hoger, i.v.m. routing, etc. Het wordt wel een klus om in de pas te blijven lopen met de maandelijkse levering. Ook moeten zaken goed worden gecoördineerd. Hier is een paar maanden geleden wel op talk-nl over gesproken, maar dit heeft nog geen concreet resultaat opgeleverd. Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Gemeentelijke herindeling in Noord-Holland
Zie: http://www.inoverheid.nl/artikel/nieuws/3083157/nederland-telt-weer-minder-gemeenten.html?utm_campaign=rssutm_source=rssutm_medium=rss Het gaat hierom: De gemeente Hollands Kroon - een samenvoeging van de voormalige gemeenten Anna Paulowna, Niedorp, Wieringen en Wieringermeer - is de jongste fusiegemeente in Nederland. Is hier al iemand mee bezig? Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Gemeentelijke herindeling in Noord-Holland
On 6-1-2012 20:09, Lennard wrote: On 6-1-2012 18:19, Frank Steggink wrote: Het gaat hierom: De gemeente Hollands Kroon - een samenvoeging van de voormalige gemeenten Anna Paulowna, Niedorp, Wieringen en Wieringermeer - is de jongste fusiegemeente in Nederland. Is hier al iemand mee bezig? http://www.openstreetmap.org/browse/changeset/10258974 http://woonplaatsgrenzen.openstreetmap.nl/?zoom=10lat=52.86994lon=5.00638layers=B0F Was OSM weer de snelste met de updates op de kaart? :-) Ook deze update was wel een persmomentje waard ;) Shame on me dat ik niet eens de moeite nam om het in de kaart te checken! Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Kadaster geeft gigabytes aan data vrij
Nou, er zijn vast wel anderen die op nieuwjaarsdag een verzoek hadden ingediend. Het was alleen een kwestie van een formuliertje invullen... Degenen die we echt moeten bedanken zijn vele anderen, o.a. Neelie Kroes, Maxime Verhagen en, niet te vergeten, Steve Coast die dankzij OSM velen de ogen heeft doen openen voor open data. Frank On 4-1-2012 14:48, Floris Looijesteijn wrote: Go Frank! via http://webwereld.nl/nieuws/109088/kadaster-geeft-gigabytes-aan-data-vrij.html Gepubliceerd: Woensdag 4 januari 2012 Auteur: Brenno de Winter Op verzoek van OpenStreetMap heeft het Kadaster vijf gigabyte aan data vrijgegeven. Daarmee kunnen verkeersroutes, grenzen en gebieden precies op de kaart worden getekend. De data werd uitzonderlijk snel vrijgegeven na een verzoek van OpenStreetMap-vrijwilliger Frank Steggink. Hij vroeg het Kadaster op 1 januari om vrijgave van de gegevens, die het verzoek op 3 januari al honoreerde. Via een link met WeTransfer is vervolgens de data uitgeleverd. OpenStreetMap Het project OpenStreetMap werkt al jaren aan een eigen open kaart en slaat met de vrijgegeven data een grote slag. Tot nu toe is het project in Nederland vooral afhankelijk van vrijwilligers die met GPS-apparatuur rondlopen en daarmee proberen een gedetailleerde kaart te maken. Voor veel informatie is dat nu niet meer nodig. Door de vrijgegeven data is de kaart niet alleen compleet, maar wordt er voortaan bovendien gewerkt met exact uitgemeten data. Verder houdt het Kadaster vanuit haar rol de informatie up-to-date, waardoor de kaarten ook nog eens actueler worden. Veel data In totaal gaat het om zo'n vijf gigabyte aan gegevens. Daarbij gaat het om onder andere zogenaamde Top10-data. Dat zijn gegevens waarmee precies wordt opgetekend waar zaken als een wegdeel, spoorbaandeel, waterdeel, gebouw, terrein, inrichtingselement, reliëf, registratief gebied, geografisch gebied of functioneel gebied zich bevindt. De exacte grenzen liggen daarmee vast. Deze zijn dan op een kaart te projecteren. Ook is een lijst met allerlei geregistreerde namen op een kaart vrijgegeven, waardoor het mogelijk wordt om informatie te duiden. Het is vooral prettig voor de vrijwilligers dat deze informatie juist is gemaakt voor cartografische toepassingen. Haken en ogen De vrijgave van gegevens is niet helemaal zonder haken en ogen. Zo blijkt de data nog niet in een open formaat te staan, maar in een gesloten Microsoft Access-bestand. Een complicatie daarbij is dat de vorm niet helemaal standaard is, waardoor de vrijwilligers nog moesten worstelen met het omzetten van gegevens in een open formaat. Een ander punt is dat het Kadaster juist gegevens vrijgeeft in een licentie die minder verplichtingen heeft dan OpenStreetMap. De verstrekte data is namelijk beschikbaar onder een Creative Commons BY-licentie. Dat betekent dat de gegevens voor hergebruik in aanmerking komen onder vermelding van de bron. OpenStreetMap werkt echter met Creative Commons BY-SA-licentie. Dat betekent dat naast bronvermelding het eindproduct ook opnieuw mag worden gebruikt, maar dat iedere afgeleide dezelfde licentie moet hebben. Als de data gebruikt wordt zal een licentie voor een nieuwe kaart moeten worden gebruikt, die hiervoor geschikt is. Niet het eerste Het is niet de eerste keer dat een grote set aan gegevens beschikbaar komt. Eerder gaf het Kadaster ook al de BAG-gegevens vrij. Deze informatie heeft een nauwkeurige weergave van gebouwen en adressen. Hierdoor werden postcodes toegankelijk, waarover eerder PostNL alleenrecht had. Die zijn sinds een recente uitspraak ook door OpenStreetMap te gebruiken. Het Ministerie van Infrastructuur en Milieu heeft ook het Nationaal Wegenbestand al beschikbaar gemaakt. In dat bestand zitten niet alleen wegen, maar ook spoor en waterwegen. Falkplan probeerde die vrijgave via een kortgeding te voorkomen, omdat zij zelf kaarten bieden en hun investering in rook zien opgaan. De rechter oordeelde echter dat de overheid gewoon data mag openbaarmaken. Blij Bij OpenStreetMap wordt enthousiast gereageerd. Ik ben blij dat de open data-politiek van de ministers Maxime Verhagen en Melanie Schultz-Van Haegen zo snel en zo veel kansen biedt. Het huidige kabinet maakt een vuist tegen het oude 'gesloten' denken, zegt Stefan de Konink, vrijwilliger bij OpenStreetMap en zelf al langer actief met open data. Zeker in de afgelopen maanden is getoond dat de landsadvocaat uit de stal wordt gehaald als vrijgave door juridische procedures wordt bedreigd. Denk aan het Nationale Wegenbestand en de postcodes in de BAG. Wat nu alleen moet blijken is of er daadwerkelijk gebruik van wordt gemaakt, en of ons dat de economische boost geeft die is beloofd. ___ 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 IJ leeggepompt!
Ook hier zie ik geen fout in JOSM. Bij het opnieuw renderen van het gebied wordt de Westhaven nu wel goed gerenderd, behalve het stukje bij ADM. Misschien kan hier Lennard of iemand anders even naar kijken, aangezien hij het renderingproces beter begrijpt. Er zit blijkbaar iets fout. Misschien een Mapnik-update? Ik pas nu niks aan aan de data. Frank On 2-1-2012 9:50, Floris Looijesteijn wrote: Als je ook nog zin hebt om naar deze te kijken kan de scheepvaart worden hervat: http://www.openstreetmap.org/?lat=52.4098lon=4.8123zoom=14layers=M Gr, Floris 2011/12/30 Frank Stegginkstegg...@steggink.org: Ik hoop het nu opgelost te hebben: http://www.openstreetmap.org/browse/changesets?bbox=4.90268%2C52.36723%2C4.97632%2C52.39065 Wat er precies aan de hand was: geen idee. Eerst dacht ik dat het komt omdat er twee multipolygonen waren, dus ik heb er een (rel. nr. 1704: komt nog uit de AND-import) verwijderd. Dat hielp niet. Later heb ik de 3 polygonen met de naam Het IJ gemerged, aangezien er verder geen verschil hiertussen zit.. Dat was nog niet voldoende, dus heb ik wat edits in de omgeving gemaakt. Uiteindelijk kon het oostelijke deel van de IJhaven pas gerenderd worden nadat ik twee eilandjes had toegevoegd die ik op Bing zag. Groeten, Frank On 30-12-2011 13:14, Floris Looijesteijn wrote: Het is weer flink mis... http://www.openstreetmap.org/?lat=52.37667lon=4.93481zoom=15layers=M gr, floris 2011/12/27 Willem Sonkewillemso...@planet.nl: Het commentaar bij deze changeset is /MP repairs (OSMI)/. De OSM Inspector [1] geeft in deze regio inderdaad multipolygoonfouten, onder meer /touching inner rings/ en /invalid geometry/. Deze gebruiker heeft overigens ook op andere plaatsen dergelijke veranderingen gedaan, waaronder in Den Haag, maar daar zie ik zo snel geen problemen op de kaart. Willem Sonke [1] http://tools.geofabrik.de/osmi/?view=multipolygonlon=4.83140lat=52.41107zoom=13overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes On 27-12-11 15:30, Piet Smits wrote: Iemand heeft op 22 december deze way uit de relatie 1704 (die het zelfde lijkt als relatie Het IJ) gehaald. Wellicht had het daar iets mee te maken: http://www.openstreetmap.org/browse/relation/1704/history Bij de monding van de Ertshaven zie (of zag) je hetzelfde. grtz, Piet Op 27-12-2011 15:15, Floris Looijesteijn schreef: http://www.openstreetmap.org/browse/way/67559262 Ja, Willem1, die wijziging is te zien. Op dit moment wordt ie ook weer goed gerenderd. Renderbugje dus denk ik... Thanks all! Groet, Floris 2011/12/27 Floris Looijesteijno...@floris.nu: Volgens mij is die historie niet actueel. De weg waar ik het in m'n andere mailtje over heb, heb ik net enorm aan lopen trekken maar die staat nog steeds op de vorige editor z'n naam. Groet, Floris 2011/12/27 Maarten Deenmd...@xs4all.nl: On 2011-12-27 14:03, Floris Looijesteijn wrote: http://www.openstreetmap.org/?lat=52.37914lon=4.92726zoom=15layers=M Wie heeft er zin om even te kijken wat er aan de hand is? Vreemd. Dat stukje IJ is sinds juli 2010 niet aangeraakt: http://www.openstreetmap.org/browse/way/67559262 3dshapes:ggmodelk = 23 name = Het IJ natural = water source = 3dShapes Lijkt ok. Ik kan in Potlatch alleen niet controleren of de way helemaal correct is (closed en continuous). Maarten ___ 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 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Het Lint, Leidsche Rijn
On 31-12-2011 15:43, Colin Smale wrote: Op dit moment is het recreatiepad Het Lint (Leidsche Rijn/Vleuten) als volgt getagd: access http://wiki.openstreetmap.org/wiki/Key:access?uselang=en-GB= yes bicycle http://wiki.openstreetmap.org/wiki/Key:bicycle?uselang=en-GB= yes cycleway http://wiki.openstreetmap.org/wiki/Key:cycleway?uselang=en-GB= no foot http://wiki.openstreetmap.org/wiki/Key:foot?uselang=en-GB= yes highway http://wiki.openstreetmap.org/wiki/Key:highway?uselang=en-GB=pedestrian http://wiki.openstreetmap.org/wiki/Tag:highway=pedestrian?uselang=en-GB motor_vehicle = no name http://wiki.openstreetmap.org/wiki/Key:name?uselang=en-GB= Het Lint source http://wiki.openstreetmap.org/wiki/Key:source?uselang=en-GB= survey surface http://wiki.openstreetmap.org/wiki/Key:surface?uselang=en-GB= asphalt Volgens de borden is het een voetpad (verkeersbord G7), met een onderbord fietsen toegestaan. Vanwege de breedte is highway=pedestrian op zijn plaats; n.a.v. het onderbord is bicycle=yes ook te verdedigen; access=yes, motor_vehicle=no en foot=yes lijkt me gewoon dubbelop. Brommers en snorfietsen zijn niet toegestaan (dit wordt echter niet gehandhaafd). Ik twijfel echter aan cycleway=no omdat dat ogenschijnlijk conflicteert met bicycle=yes. Bovendien is het niet gebruikelijk om te taggen wat iets NIET is (anders kan ik er ook shop=no opzetten - waar houdt het op?). Ik stel dan ook voor om cycleway=no te verwijderen. Wie schiet? Colin ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Hoi Colin, Ik doe een poging: * access = yes: redundante tag, kan dus weg. Yes is de defaultwaarde. * bicycle = yes: laten staan. * cycleway = no: heeft geen zin, kan dus weg. De cycleway tag is ervoor bedoeld om een bijzondere situatie aan te geven voor het fietspad, bijv. fietssuggestiestroken of dat fietsers tegen eenrichtingverkeer mogen fietsen. * foot = yes: redundant t.o.v. highway=pedestrian, kan dus weg. * motor_vehicle = no: laten staan. Volgens de map features pagina is een motorvoertuig niet per definitie verboden op highway=pedestrian. Denk bijv. aan een winkelstraat, waar goederen geleverd moeten kunnen worden. Rest kan wel blijven staan. Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Het IJ leeggepompt!
Ik hoop het nu opgelost te hebben: http://www.openstreetmap.org/browse/changesets?bbox=4.90268%2C52.36723%2C4.97632%2C52.39065 Wat er precies aan de hand was: geen idee. Eerst dacht ik dat het komt omdat er twee multipolygonen waren, dus ik heb er een (rel. nr. 1704: komt nog uit de AND-import) verwijderd. Dat hielp niet. Later heb ik de 3 polygonen met de naam Het IJ gemerged, aangezien er verder geen verschil hiertussen zit. Dat was nog niet voldoende, dus heb ik wat edits in de omgeving gemaakt. Uiteindelijk kon het oostelijke deel van de IJhaven pas gerenderd worden nadat ik twee eilandjes had toegevoegd die ik op Bing zag. Groeten, Frank On 30-12-2011 13:14, Floris Looijesteijn wrote: Het is weer flink mis... http://www.openstreetmap.org/?lat=52.37667lon=4.93481zoom=15layers=M gr, floris 2011/12/27 Willem Sonkewillemso...@planet.nl: Het commentaar bij deze changeset is /MP repairs (OSMI)/. De OSM Inspector [1] geeft in deze regio inderdaad multipolygoonfouten, onder meer /touching inner rings/ en /invalid geometry/. Deze gebruiker heeft overigens ook op andere plaatsen dergelijke veranderingen gedaan, waaronder in Den Haag, maar daar zie ik zo snel geen problemen op de kaart. Willem Sonke [1] http://tools.geofabrik.de/osmi/?view=multipolygonlon=4.83140lat=52.41107zoom=13overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes On 27-12-11 15:30, Piet Smits wrote: Iemand heeft op 22 december deze way uit de relatie 1704 (die het zelfde lijkt als relatie Het IJ) gehaald. Wellicht had het daar iets mee te maken: http://www.openstreetmap.org/browse/relation/1704/history Bij de monding van de Ertshaven zie (of zag) je hetzelfde. grtz, Piet Op 27-12-2011 15:15, Floris Looijesteijn schreef: http://www.openstreetmap.org/browse/way/67559262 Ja, Willem1, die wijziging is te zien. Op dit moment wordt ie ook weer goed gerenderd. Renderbugje dus denk ik... Thanks all! Groet, Floris 2011/12/27 Floris Looijesteijno...@floris.nu: Volgens mij is die historie niet actueel. De weg waar ik het in m'n andere mailtje over heb, heb ik net enorm aan lopen trekken maar die staat nog steeds op de vorige editor z'n naam. Groet, Floris 2011/12/27 Maarten Deenmd...@xs4all.nl: On 2011-12-27 14:03, Floris Looijesteijn wrote: http://www.openstreetmap.org/?lat=52.37914lon=4.92726zoom=15layers=M Wie heeft er zin om even te kijken wat er aan de hand is? Vreemd. Dat stukje IJ is sinds juli 2010 niet aangeraakt: http://www.openstreetmap.org/browse/way/67559262 3dshapes:ggmodelk = 23 name = Het IJ natural = water source = 3dShapes Lijkt ok. Ik kan in Potlatch alleen niet controleren of de way helemaal correct is (closed en continuous). Maarten ___ 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 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Bushaltes en GSM antennes
On 20-12-2011 0:38, Stefan de Konink wrote: On Mon, 19 Dec 2011, Henk Hoff wrote: Omdat je het zo vriendelijk vraagt: Kun je aangeven welke changesets (nummertjes) akkoord zijn en welke niet. Je kunt je changesets hier vinden: http://www.openstreetmap.org/user/Stefan%20de%20Konink/edits Zijn maar 8 pagina's. Valt me dus In dat geval valt een: input type='submit' name='odblok' value='yes' input type='submit' name='odblok' value='no' ...ook wel mee :) Even afhankelijk hoe dat zodadelijk wordt opgelost, zal ik je mogelijk later vragen een extra account te maken waar we mogelijk je geakkoordeerde changesets naar verhuizen. Changesets die niet akkoord zijn, kun je daarvan ook aangeven waarom niet? Oftewel: welke dataset komen ze van. input type='text' name='reason' Zijn er nog meer dingen die je van me zou willen weten? Dan hebben we in ieder geval de requirements om een 'partial' odblok te geven. Zij die eerst software schrijven om een verandering te ondersteunen groeten u. Zij die zich liever de moeite uitsparen, omdat het voor 99% van de users geen issue is, groeten u terug ;) Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] uitspraak rechtzaak NWB
On 15-12-2011 1:03, dbuss...@goudappel.nl wrote: de rechter staat vrijgave van het NWB toe en wijst niet alleen het spoedeisende belang af (dat was makkelijk geweest) maar legt ook uit waarom het inhoudelijk niet waarschijnlijk is dat het vrijgeven van het NWB verboden is: _http://zoeken.rechtspraak.nl/ResultPage.aspx?snelzoeken=tsearchtype=ljnljn=BU8010_ http://zoeken.rechtspraak.nl/ResultPage.aspx?snelzoeken=tsearchtype=ljnljn=BU8010 Nu afwachten onder welke licentie het NWB wordt vrijgegeven. Rechtstreekse import in OSM zou onzin zijn gezien de kwaliteit van OSM gemiddeld veel beter is. Wat ik wel wil doen is een applicatie maken die inzichtelijk maakt waar wij in OSM hele wijken of verbindingen missen en omgekeerd. Op de OSM kant kan ik me een WMS-onderlegger in JOSM voorstellen waar deze wegen initieel worden overgetrokken (bij gebrek aan beter) en van een tag hier moet nog iemand langs kunnen worden voorzien. RWS zal onze wegen vanwege licentie niet zomaar kunnen overnemen maar de melding dat er iets mist wel als aanleiding nemen om de informatie bij de wegbeheerde op te vragen. Zo kunnen we wederzijds van elkaar profiteren. Deze werkwijze wordt ook in Canada gebruikt door National Resources Canada, die o.a. de topografische kaart samenstelt. Hun data is PD en kan dus in OSM worden geïmporteerd. Andersom is niet mogelijk, maar ze gebruiken wel OSM om veranderingen in de gaten te houden en ze gaan dan alsnog zelf data inwinnen. Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] uitspraak rechtzaak NWB
On 15-12-2011 17:35, Stefan de Konink wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 15-12-11 17:13, Frank Steggink schreef: Deze werkwijze wordt ook in Canada gebruikt door National Resources Canada, die o.a. de topografische kaart samenstelt. Hun data is PD en kan dus in OSM worden geïmporteerd. Andersom is niet mogelijk, maar ze gebruiken wel OSM om veranderingen in de gaten te houden en ze gaan dan alsnog zelf data inwinnen. Toch verschrikkelijk jammer? Dubbel werk, waarom zou dit juist vanaf hoogwaardige data leveranciers eenrichtingverkeer (naar OSM) moeten zijn? Het antwoord weet je zelf wel: licentietechnische redenen. Ook al zouden deze niet meespelen, dan zou ik nog wel andere redenen kunnen verzinnen om data opnieuw in te winnen: kwaliteit, of de wil om alleen eigen data in een dataset te hebben. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Semi automatisch BAG voorstel
On 9-12-2011 21:49, Robert Elsenaar wrote: lijkt me een strak plan. Na alles tijdens de borrel. BAG BABBEL. Met vriendelijke groeten, Robert Elsenaar (Verzonden vanaf Mobile) Stefan de Konink ste...@konink.de schreef: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 09-12-11 15:50, Gertjan Idema schreef: Wat is op dit moment de status van deze Thread? Ik ben samen met It's so funny http://www.openstreetmap.org/user/It's%20so%20funny (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. Het zou erg prettig zijn als we hier morgen eens face-to-face over kunnen praten. Woonplaats grenzen was niet echt de issue... Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk7iPYsACgkQYH1+F2Rqwn1+WQCfWHg5/2HhSxi8Ppy6ra75aaV4 XhMAnAyrnCAjx9ZvuIlKDyjDWyn6Hseu =VwcA -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 Eens. Aangezien Just er is, kunnen we goed zijn BAG-expertise even lenen :) Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] download niet meer alles?
On 4-12-2011 15:45, Martien Scheepens wrote: Een way bestaat uit twee of meer punten. De renderer verbindt deze punten netjes en ook de editor laat een dun lijntje zien. Als jij echter een gebied download en er geen van de twee verbindende punten in ligt, krijg jij de way niet te zien. De editor kijkt namelijk alleen maar naar punten binnen het gebied in de database. Het omgekeerde geval valt meestal iets minder op. Als jij maar een klein stukje way wilt bewerken, krijg je altijd de hele way in de editor te zien. Soms tientallen kilometers lang, omdat de way tussendoor nergens eindigt. Kortom niet echt iets aan de hand. Mocht je nu graag willen dat je wel alle ways in je editor krijgt als ze wel snijden, maar geen punt binnen het gebied ligt, dan moet ik er helaas op wijzen dat dit betekent dat je bij iedere vraag de halve database moet controleren en daarmee de performance heel slecht wordt. Ter info: dat is precies de reden dat PostGIS, Oracle Spatial en andere databases een ruimtelijke index hebben. Hierdoor hoeft alleen de index te worden geraadpleegd. Ook al gebruikt OSM PostgreSQL (als ik het goed heb), wordt door de API voor het downloaden geen gebruik gemaakt van PostGIS. Dit gebeurt wel voor het renderen door Mapnik, zodat je op de kaart wel altijd alle objecten ziet. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] [OT] Nederlandstalig OSGeo chapter
Hoi, Bericht van de Nederlandstalige mailinglijst van OSGeo (de open source geospatial foundation). Ik denk dat er onder diverse OSM'ers die veel gebruik maken van open source software eveneens interesse bestaat. Tijdens de FOSS4G 2011 conferentie in Denver is het idee ontstaan om het Dutch local chapter nieuw leven in te blazen. Een local chapter kan worden opgezet in de vorm van een vereniging maar het kan ook een meer informeel karakter hebben waarin een groep vrijwilligers activiteiten organiseren. De bedoeling is om tijdens het GIN-congres op 1 december 2011 een 'birds-of-a-feather' (BoF) sessie te houden om te kijken wat de behoefte is onder de GIS-gebruikers en -ontwikkelaars in Nederland en welke activiteiten we als local chapter zouden kunnen starten. Wil je een meer actieve rol spelen, maak dan een wiki-account aan [op wiki.osgeo.org] en voeg je naam toe aan het overzicht van Nederlandstalige OSGeo leden: http://wiki.osgeo.org/wiki/Nederland#Nederlandstalige_OSGeo_leden Laat het ook weten als je dit initiatief ondersteunt, ook al kun je niet op het GIN-congres aanwezig zijn. Let op: dit gaat _niet_ over een eventueel OSM-nl chapter, waar in het verleden over is gediscussieerd! Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] FRN Stadsregio Arnhem - Nijmegen
On 19-11-2011 11:47, Jo wrote: Hallo, Ik maak stukje bij beetje vooruitgang met het nazicht van de fietsroutenetwerken. Ik ga aan de oostkant naar het noorden en het lijkt erop dat ik assistentie krijg aan de westelijke kant, wat ik ten zeerste apprecieer. (Bedankt Jeroen) Nu ben ik dus bij het netwerk Arnhem - Nijmegen aanbelandt. Is dit echt 1 netwerk? Meer naar het zuiden omvatte zo'n stadsregio slechts 1 grootstad, die ongeveer even ver van elkaar lagen als Arnhem en Nijmegen. Ik vind in dit netwerk 5 keer een knooppunt met het nummer 01. 2 keer, of 3 keer, dat had ik al gezien en daar ben ik ook niet echt blij mee, maar goed, dat is persoonlijke voorkeur. 5 keer lijkt mij echter een indicatie dat er ergens iets foutgelopen is bij het toewijzen van knooppunten aan netwerken. Sommige van deze knooppunten liggen zelfs in Duitsland. Heeft een Nederlandse provincie/stadsregio echt een heel netwerk aangelegd in Duitsland? Een grensoverschrijdend knooppunt hier of daar, of een route die een stukje Duitsland doorkruist, daar kan ik me iets bij voorstellen. Maar meerdere verbonden knooppunten? Dat kan toch niet? Vandaar dus mijn vraag/vragen: Is het OK dat ik die Duitse knooppunten in een apart netwerk onderbreng? Zou het heel erg zijn als Arnhem en Nijmegen elk in een apart netwerk worden ondergebracht? Ik kan niet ter plaatse gaan kijken wat er op de bordjes staat. Als daar effectief Stadsregio Arnhem - Nijmegen op staat, zal ik me erbij moeten neerleggen dat het allemaal in 1 relatie moet worden ondergebracht, maar ik vraag het toch liever even, of dat inderdaad wel zo is. mvg, Jo ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Hallo Jo, Ik weet ook niet wat er op de bordjes staat, maar Arnhem en Nijmegen vormen samen (met nog 18 andere gemeenten) wel één stadsregio: http://nl.wikipedia.org/wiki/Stadsregio_Arnhem_Nijmegen . De huidige aanduiding lijkt me wel correct. V.w.b. de Duitse knooppunten: aangezien Nijmegen pal aan de grens ligt en de grens hier een hap uit Nederland neemt, kan ik me wel voorstellen dat er meerdere verbonden knooppunten in Duitsland liggen. Gaat het inderdaad om de genummerde knooppunten hier: http://osm.org/go/0GFkYYy--?layers=C ? Deze liggen precies in de hap. Het zijn er maar een stuk of 10. Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
Stefan, Oliver heeft het over het importeren van BAG-data in OSM, niet om toevoegingen van OSM-gebruikers weer aan de BAG te voeden. Dit kan ook helemeal niet. De BAG wordt bijgehouden door de bronhouders; de gemeenten. Wat authentieke BAG-data is, wordt door deze bronhouders bepaald. Er is geen mogelijkheid om OSM op de een of andere manier op de Landelijke Voorziening aan te sluiten, om de BAG van extra attributen te voorzien. Wij kunnen alleen besluiten om BAG-data uit de LV te onttrekken en deze in OSM te importeren. (Wat dit betreft heb ik wel twijfels over het databankenrecht, maar dat is een andere discussie.) Quoting Stefan de Konink ste...@konink.de: Op 02-11-11 21:02, Oliver Heesakkers schreef: OSM is echter veel laagdrempeliger. Onzin, als OSM laagdrempelig was kwamen er niet tal van mensen naar mij toe met de vraag hoe ze uberhaupt data uit OSM kunnen halen. Vector data ja, dat ze kunnen verwerken in met software. OSM XML != Standaard. Er staat laagdrempelig_er_. Ik zie ook niet een leek zomaar met GML data in de weer gaan. Geimporteerde BAG-data geeft de mapper gelegenheid om namen, ingangen, openingstijden, etc. toe te voegen en geeft die mapper ook makkelijk de gelegenheid om de plaatsing van wegen te orienteren aan de gebouwen. Een GML bestand geeft diezelfde functionaliteit. Ik mis het punt. Omdat die tags niet in IMGeo (het uitwisselingsformaat voor BAG) gedefinieerd staan? De huisnummers (en binnenkort wellicht postcodes) die BAG levert zijn relevante en goed bruikbare data die ook juist voor afgeleide (navigatie)producten juist heel interessant zijn. Het bij elkaar houden van de data voorkomt dan licentievraagstukken en compatibiliteitsproblemen. Het introduceert alleen maar licentie vraagstukken. De vraag: waarom BAG data geedit door OSM'ers opeens niet meer PD zijn bijvoorbeeld. De OSM-licentie blijft gelden (be it CC-BY-SA 2.0 of ODbL). Alles wat in OSM zit, voldoet hieraan. Er is geen enkel bezwaar om PD data te importeren. Afgeleide data hoeft, per definitie, niet PD te blijven. De originele bron blijft dat natuurlijk wel. Anders zou daar een share-alike clausule aanhangen. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
Quoting Stefan de Konink ste...@konink.de: Op 03-11-11 08:40, Frank Steggink schreef: Stefan, Oliver heeft het over het importeren van BAG-data in OSM, niet om toevoegingen van OSM-gebruikers weer aan de BAG te voeden. Dit kan ook helemeal niet. De BAG wordt bijgehouden door de bronhouders; de gemeenten. Wat authentieke BAG-data is, wordt door deze bronhouders bepaald. Er is geen mogelijkheid om OSM op de een of andere manier op de Landelijke Voorziening aan te sluiten, om de BAG van extra attributen te voorzien. Wij kunnen alleen besluiten om BAG-data uit de LV te onttrekken en deze in OSM te importeren. (Wat dit betreft heb ik wel twijfels over het databankenrecht, maar dat is een andere discussie.) Zover ik heb begrepen kan er bij iedere bronhouder worden gerapporteerd als er dingen in de BAG niet kloppen. Succes als je deze weg wilt bewandelen :) Databankenrecht waarop? BAG licentie gelezen? Niet recent, dus het is me ontgaan. Google brengt me wel op deze site uit: http://wiki.openstreetmap.org/wiki/BAG . Jeroen's samenvatting waar naar verwezen wordt laat het databankenrecht nog als open punt (onverlet het auteursrecht). Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
On 11-11-03 05:13 PM, Stefan de Konink wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 03-11-11 14:19, Frank Steggink schreef: Succes als je deze weg wilt bewandelen :) Je kunt maar beter de eerste zijn he :) Terugmelden onjuistheden BAG Antwoord Als u gerede twijfel heeft over de juistheid van de informatie in de BAG, dan kunt u dit per email melden bij b...@kadaster.nl. In het onderwerpveld van de e-mail dient u de gemeente waarbinnen het object valt te vermelden. Dat lijkt me nu een perfect e-mail adres om automatisch verbetering naar toe te sturen :) Databankenrecht waarop? BAG licentie gelezen? Niet recent, dus het is me ontgaan. Google brengt me wel op deze site uit: http://wiki.openstreetmap.org/wiki/BAG . Jeroen's samenvatting waar naar verwezen wordt laat het databankenrecht nog als open punt (onverlet het auteursrecht). Mag ik de BAG-data aan derden verstrekken? Antwoord De BAG is er voor iedereen! Hoewel de BAG in eerste instantie gebouwd is om overheden efficiënter en klantgerichter te laten werken, is de BAG ook beschikbaar voor burgers en bedrijven. Het beleid van de Rijksoverheid is immers dat overheidsinformatie op een makkelijke en goedkope wijze ter beschikking moet worden gesteld aan iedereen die daar behoefte aan heeft. In beginsel is er aan hergebruik van deze informatie geen belemmering gekoppeld. Een uitzondering hierop vormt de postcode. Vanwege een oude afspraak tussen de overheid en PostNL mag de postcode uit de BAG niet voor commerciële doeleinden worden gebruikt. De overheid heeft deze afspraak opgezegd en deze belemmering vervalt uiterlijk 1 februari 2012. Daarna mag, ook de postcode uit de BAG voor commerciële doeleinden worden gebruikt, net zoals alle andere gegevens uit de BAG. Is de FUD nu eigenlijk over? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk6yvYwACgkQYH1+F2Rqwn1riACfXX9f/IsJBLwOw59yeTpuqcqB /YoAn2EoPtB3ncEss3W6PiOAG0KtNXYC =j4/p -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Volgens Google is de zin Mag ik de BAG-data aan derden verstrekken? en het antwoord inderdaad op de Kadaster-site te vinden (. Goed nieuws dus ;) Alleen jammer dat hun site het net lijkt te hebben begeven, omdat ik een foutmelding krijg. Het zou beter zijn als het Kadaster dit op een zodanige plek neerzet dat het statement niet door een ASP.NET fout onbereikbaar wordt. Ik had dit antwoord nog niet gezien, omdat ik OSM minder intensief volg, maar toch de BAG-discussie interessant vind. Ik wilde geen FUD zaaien, maar had zelf nog last van een restant 'D'. Je weet dat ik pro-open data ben, maar ik heb geen tijd en zin om achteraf met juridische zaken geconfronteerd te worden bij overhaaste beslissingen. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Semi automatisch BAG voorstel
Hoi Robert, Aangezien het jachtseizoen voor de meeste soorten wild op 15 oktober is geopend, begin ik met schieten ;) Uiteraard draag ik zelf ook wat wild aan. On 11-11-03 08:59 PM, Robert Elsenaar wrote: Nederland is opgedeelt in blokken (bv 5 bij 5 km) of in gemeentegrenzen. Dit is niet relevant voor het idee. Dit is wel degelijk relevant. Een 5x5 km grid is een willekeurige onderverdeling in Nederland. Je krijgt dan ook te maken met een zeer ongelijke verdeling van de werklast. Vergelijk een blok van 5x5 hartje Amsterdam met een willekeurige stek op de Veluwe. Aangezien opdeling in gemeenten ook een ongelijke verdeling maakt, wil ik hierbij pleiten voor een onderverdeling in 4-cijferige postcodegebieden. Dit is behapbaar, omdat de spreiding in omvang veel minder divers is dan bij gemeenten, laat staan een willekeurig grid. De postcodes zelf kunnen weliswaar nog niet gebruikt worden, maar we kunnen de data wel zo opknippen. Voor elk van deze 'blokken' kan de gebruiker een aanvraag doen van klaarstaande wijzigingen in de BAG data. Het moedersysteem heeft al enige zaken voorbereid voor de aanvraag gedaan kan worden. - Het moeder systeem heeft alle updates van BAG opgesplitst in 'blok-updates'. Merk op dat voor ieder blok niet voor iedere maand een update is. Bij geen wijziging ontstaat er voor dat blok geen blok-update. Merk ook op dat ieder blok in het begin altijd 1 blok-update heeft en dat deze alle BAG data uit dat blok bevat. BAG is in het begin immers nog niet op dat blok in OSM gebracht. Deze blok-update wordt de 'init-update' genoemd. Iedere volgende blok-update bevat alleen de wijzigingen uit een betreffende maand. Op een zeker moment kunnen er dus voor ieder blok verschillende hoeveelheden blok-updates aanwezig zijn. Een Delta Uitlevering BAG (DUB) van een blok heeft de volgende kenmerken: - De uitlevering wordt gemaakt op het moment van aanvraag - De uitlevering bevat de geaggregeerde BAG gegevens vanaf Laatste Update Datum (LUD) (Voor de eerste uitlevering van ieder blok (init) is deze datum bv 01-01-2011) - Bestand heeft een unieke code. - Bestand is in .OSM formaat zodat deze direct in JOSM geladen kan worden. Delta's (was-wordt) lijken leuk, maar zijn dat absoluut niet. Het werkt alleen voor nieuwe toevoegingen, die niet in OSM zitten. Met updates en verwijderingen moet gebruik worden gemaakt van de bestaande way-/relation-ID's in OSM én het juiste versienummer. Daarbij komt nog dat je in een OSM bestand (ik neem aan dat je dan de JOSM smaak bedoelt) niet ziet wat er verwijderd is. Ook houdt deze benadering geen rekening met wijzigingen die gebruikers aan bestaande data hebben toegevoegd. Als het ID en versienummer zou kloppen, dan moeten wijzigingen alle gebruikers-tags toevoegen. Dit gaat in theorie alleen werken als het proces dat de DUB-bestanden maakt gebruik maakt van up-to-date OSM data én als de gebruiker zsm de wijzigingen gaat posten. Dit neemt nog steeds niet het bezwaar weg dat dit semi-geautomatiseerd is. Aangezien je werkzaam bent in de ICT, weet je ook dat software niet altijd 100% klopt ;) Changesets kúnnen gerevert worden, maar dat moet zeker geen gewoonte worden! Activiteiten DUB site: De DUB site is een site waarin de ingelogde OSM gebruiker op de kaart van OSM 1 blok kan aangeven en vervolgens daarvan een DUB kan bestellen. De DUB site aggregeert alle blok-updates vanaf de LUD. De gebruikersnaam, de aanvraag datum en een unieke code worden in een database opgeslagen. De site controleert automatisch of de unieke code van een uitstaande DUB voorkomt in de omschrijving van de changesets. Komt deze voor dan wordt het record van de DUB verwijderd en krijgt het blok een LUD die gelijk is aan de uitgifte datum van de net verwijderde DUB. De geldigheid van een uitlevering kan gesteld worden op 1 maand. Heeft de aanvrager zijn aanvraag niet omgezet in een valide changeset, dan kan via een mail het systeem hem hiertoe aansporen dit alsnog te doen. (Eventueel kan voor voorkomende gevallen een mogelijkheid geschapen worden om de DUB zonder changeset vrij te geven zonder de aanpassingen door te hebben gevoerd in OSM. Het DUB record wordt wel verwijderd, maar de LUD niet aangepast. Wordt een aanvraag gedaan voor een blok waarvan reeds een DUB uitstaat, dan kan deze geweigerd worden en verwezen worden naar de betrokken gebruiker. Onderling kan een oplossing voor dit oponthoud gevonden worden. (Vrijgeven van het blok?) Ik vind dit teveel klinken als een technische oplossing (unieke ID's, locking, geldigheidsperiodes), i.p.v. een oplossing die gaat werken. De DUB-site is een veel te bazig systeem. Ook in dit verhaal blijf ik missen hoe je met gewijzigde en verwijderde features om denkt te gaan. De gebruiker vergelijkt na ontvangst de DUB.OSM met de huidige OSM gegevens en brengt op deze laatste de wijzigingen aan. Is de gebruiker klaar dan upload hij de gegevens en vernoemd in de omschrijving van de changeset de
[OSM-talk-nl] Fwd: Re: Semi automatisch BAG voorstel
Hoi Robert, On 11-11-03 10:21 PM, rob...@elsenaar.info wrote: Ik voel me allerminst opgejaagd wilt. Je 'alternatief' zie ik meer als een zinvolle aanvulling op mijn idee dan een discriminerend alternatief. Mijn feedback is inderdaad bedoeld als aanvulling. Ik kan me trouwens indenken dat je je niet opgejaagd voelt, aangezien jacht op zondag(middag) (en tussen zonsondergang en -opgang) niet toegestaan is. Positieve punten: - Opdelen in anders soortige 'blokken' stuit bij mij op geen bezwaar, Ik gaf al aan dat die opdeling voor mijn idee niet relevant is. Voor de uiteindelijke uitwerking natuurlijk wel. en dat gaf je juist aan. - De een DUB opgedeeld wordt in drie bestanden (INS, CHG, DEL) is een uitstekende toevoeging. Leuk wellicht als je ook voor deze vormen kunt kiezen. Uit de door jou gekozen benaming valt af te leiden dat je uit het 8.3 tijdperk stamt ;) Wat mij betreft is mijn alternatief geen keuze t.o.v. jouw voorstel, vanwege de eerder genoemde redenen. - Hoe je de changeset laat corresponderen met de DUB's is mij gelijk. Mij leek een unieke ID, gegenereerd door de website zelf een beter idee. Dat dit uiteindelijk niet via de changeset, maar via een handmatige terugkoppeling, dat vind ik niet zo belangrijk. Het laatste zorgt er welvoor dat de gebruiker een verwerking kan uitvoeren door meer CS te up[loaden. Maar goed. Een handmatige stap, tevens als controle, is een goede aanvulling in een proces dat redelijk foutgevoelig is. Ook bij het handmatig verwerken van mutaties kunnen fouten optreden. Aan meerdere changesets per upload had ik nog niet eens gedacht. Dus afvinkmogelijkheid erbij. Voor mutaties verwacht ik niet dat dit nodig zal zijn, maar wel voor de initiële upload. - Je laat de basis van mijn idee volledig overeind: Ik vind het belangrijk als BAG data op eenvoudige manier beschikbaar komt voor de grote massa en in een vorm waarbij de verwerking niet meer vaardigheden vraagt dan bij het normale mappen voor gevorderden. Het zinvol opdelen van dit werk is altijd een goed idee. Over de invulling kan men twisten ;) Grote massa vind ik hier overdreven, maar dat dit breder gedragen moet worden dan door een driekoppig groen monster is een feit ;) Ik hoop dat daadwerkelijk dat dit idee bij de groep wordt omarmt en gerealiseerd wordt. Helaas heb ik te weinig technische kennis om in die fase mijn bijdrage te leveren :-( De uitwerking omvat meer dan het inrichten van de omgeving en het schrijven van code. Testen en documentatie zijn minstens net zo belangrijk, zeker om meer, maar tevens minder ervaren gebruikers erbij te betrekken (alhoewel een bepaalde mate van vaardigheid met JOSM vereist is). Dit proces is en blijft redelijk gecompliceerd. Het is niet eenvoudiger te maken dan een bepaald niveau. Enige discipline blijft dus nodig. Goede documentatie ondersteunt daarin. Ik wil jou dit werk niet aansmeren, maar mensen ervan bewust maken dat het niet bij programmeren alleen ophoudt. Frank groet Robert Citeren Frank Stegginkstegg...@steggink.org: Hoi Robert, Aangezien het jachtseizoen voor de meeste soorten wild op 15 oktober is geopend, begin ik met schieten ;) Uiteraard draag ik zelf ook wat wild aan. On 11-11-03 08:59 PM, Robert Elsenaar wrote: Nederland is opgedeelt in blokken (bv 5 bij 5 km) of in gemeentegrenzen. Dit is niet relevant voor het idee. Dit is wel degelijk relevant. Een 5x5 km grid is een willekeurige onderverdeling in Nederland. Je krijgt dan ook te maken met een zeer ongelijke verdeling van de werklast. Vergelijk een blok van 5x5 hartje Amsterdam met een willekeurige stek op de Veluwe. Aangezien opdeling in gemeenten ook een ongelijke verdeling maakt, wil ik hierbij pleiten voor een onderverdeling in 4-cijferige postcodegebieden. Dit is behapbaar, omdat de spreiding in omvang veel minder divers is dan bij gemeenten, laat staan een willekeurig grid. De postcodes zelf kunnen weliswaar nog niet gebruikt worden, maar we kunnen de data wel zo opknippen. Voor elk van deze 'blokken' kan de gebruiker een aanvraag doen van klaarstaande wijzigingen in de BAG data. Het moedersysteem heeft al enige zaken voorbereid voor de aanvraag gedaan kan worden. - Het moeder systeem heeft alle updates van BAG opgesplitst in 'blok-updates'. Merk op dat voor ieder blok niet voor iedere maand een update is. Bij geen wijziging ontstaat er voor dat blok geen blok-update. Merk ook op dat ieder blok in het begin altijd 1 blok-update heeft en dat deze alle BAG data uit dat blok bevat. BAG is in het begin immers nog niet op dat blok in OSM gebracht. Deze blok-update wordt de 'init-update' genoemd. Iedere volgende blok-update bevat alleen de wijzigingen uit een betreffende maand. Op een zeker moment kunnen er dus voor ieder blok verschillende hoeveelheden blok-updates aanwezig zijn. Een Delta Uitlevering BAG (DUB) van een blok heeft de volgende kenmerken: - De uitlevering wordt gemaakt op het moment van aanvraag - De
Re: [OSM-talk-nl] Semi automatisch BAG voorstel
On 11-11-03 10:37 PM, Stefan de Konink wrote: Ik vind Franks postcode idee nog beter dan mijn woonplaats idee. Maar ik heb wel een aantal bezwaren bij het 'nieuw' en 'gewijzigd'. Wanneer is iets nieuw? Als het nog niet is geimporteerd? Is iedere wijziging dan 'nieuw'? Voor de bepaling van wat nieuw en wat gewijzigd is, wordt alleen naar de BAG-data zelf gekeken. De initiële levering is per definitie nieuw. Ook BAG-objecten die zijn ontstaan tussen de begin- en einddatum zijn nieuw. Gewijzigd is een BAG-object dat al eerder bestond, maar waarvan de eigenschappen (geometrie of attributen) gewijzigd zijn tussen de begin- en einddatum. Ik neem aan dat dit in de metadata af te leiden is. NEN3610-objecten (dus ook BAG-objecten, want het IMGeo-model is op NEN3610 gebaseerd) hebben een vaststaand ID, dus de datum van laatste wijziging, of puur het feit dat een object in het BAG-mutatiebestand voorkomt (afhankelijk van de te kiezen levering) zegt genoeg. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] BAG-update: ook bruikbaar voor BRT?
On 11-11-03 10:52 PM, Frank Steggink wrote: On 11-11-03 10:37 PM, Stefan de Konink wrote: Ik vind Franks postcode idee nog beter dan mijn woonplaats idee. Maar ik heb wel een aantal bezwaren bij het 'nieuw' en 'gewijzigd'. Wanneer is iets nieuw? Als het nog niet is geimporteerd? Is iedere wijziging dan 'nieuw'? Voor de bepaling van wat nieuw en wat gewijzigd is, wordt alleen naar de BAG-data zelf gekeken. De initiële levering is per definitie nieuw. Ook BAG-objecten die zijn ontstaan tussen de begin- en einddatum zijn nieuw. Gewijzigd is een BAG-object dat al eerder bestond, maar waarvan de eigenschappen (geometrie of attributen) gewijzigd zijn tussen de begin- en einddatum. Ik neem aan dat dit in de metadata af te leiden is. NEN3610-objecten (dus ook BAG-objecten, want het IMGeo-model is op NEN3610 gebaseerd) hebben een vaststaand ID, dus de datum van laatste wijziging, of puur het feit dat een object in het BAG-mutatiebestand voorkomt (afhankelijk van de te kiezen levering) zegt genoeg. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Ik zat net nog te denken aan de BasisRegistratie Topografie (BRT) die per 1 januari a.s. gratis wordt. Dit is dus inclusief Top10NL, de dataset waar het PBL de 3dShapes dataset uit heeft afgeleid. Mits de BRT onder een gunstige licentie beschikbaar komt en mits de 3dShapes data zonder al te veel poespas is op te waarderen, dan zouden we hetzelfde proces kunnen gebruiken om de landuse data bij te werken (en andere Top10NL objecten toe te voegen, zoals kleine waterlopen, muren, etc.). De verversingscyclus zal veel onregelmatiger zijn dan bij de BAG, alhoewel ik niet weet wat de huidige situatie is. (Er geldt wel een soortgelijke terugmeldplicht als voor de BAG, dus het zou kunnen zijn dat updates veel continuer zijn.) Met het opwaarderen van 3dShapes bedoel ik het volgende: * actualiseren data (3dShapes is door de bank genomen 6 jaar oud) * gebouwen worden niet meegenomen, want daar hebben we de BAG voor * bijwerken / update van tags, om zo de ongelukkige categorisering van 3dShapes te niet te doen (combinatie bos en heide - natuur), en zelfs gebruik maken van meer specifieke tagging (bijv. loof-/naaldbos). De randvoorwaarden zijn als volgt: * de geometrie moet niet al te veel afwijken, anders zouden we net zo goed overnieuw kunnen beginnen, maar met de opgedane ervaring raad ik dat niemand aan. * de hoeveelheid werk moet in eerste instantie behapbaar zijn om de actualiseringsslag te doen. Zomaar een ideetje op de late avond ;) Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Semi automatisch BAG voorstel
On 11-11-03 11:06 PM, Stefan de Konink wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 03-11-11 22:52, Frank Steggink schreef: On 11-11-03 10:37 PM, Stefan de Konink wrote: Ik vind Franks postcode idee nog beter dan mijn woonplaats idee. Maar ik heb wel een aantal bezwaren bij het 'nieuw' en 'gewijzigd'. Wanneer is iets nieuw? Als het nog niet is geimporteerd? Is iedere wijziging dan 'nieuw'? Voor de bepaling van wat nieuw en wat gewijzigd is, wordt alleen naar de BAG-data zelf gekeken. De initiële levering is per definitie nieuw. Ook BAG-objecten die zijn ontstaan tussen de begin- en einddatum zijn nieuw. Gewijzigd is een BAG-object dat al eerder bestond, maar waarvan de eigenschappen (geometrie of attributen) gewijzigd zijn tussen de begin- en einddatum. Oke, maar hoe weet je dan of die objecten al in OSM staan? Zoals gezegd wordt alleen naar de BAG-data zelf gekeken en niet naar OSM om de drie changeset-bestanden te maken. De data danwel historie bevat alle benodigde informatie. De verantwoordelijkheid voor de initiële vulling, verwijdering van (redundant geworden) 3dShapes gebouwen, overzetten van tags, etc. ligt bij de lokale gebruiker. Hij is uiteindelijk de scheidsrechter die bepaalt welke BAG-objecten in OSM terechtkomen en hoe dat gebeurt. Het in te richten proces is ervoor bedoeld om hem te ondersteunen. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Semi automatisch BAG voorstel
On 11-10-31 10:22 PM, Stefan de Konink wrote: Het probleem met het uitgeven van 'een OSM bestand' is het ontbreken van de garantie van het kunnen blijven volgen. Dat kan of door het via 1 tool te importeren die objectids bijhoud, of via een tool die externeIDs in de k/v pairs zet. Synchroon houden met tags gaat inderdaad niet werken. Alles wat we als extra tags toevoegen, _zal_ verloren gaan, bewust of onbewust. Ik mag aannemen dat in de metadata van een BAG-object de laatste wijzigingsdatum staat. Die kun je natuurlijk wel gebruiken. Evt. een viewertje eromheen, waarbij de gebruiker een datum kan opgeven. Vervolgens wordt er een kaartje getoond waar de BAG-objecten die nieuwer zijn een andere kleur krijgen. Desnoods kun je er een RSS-feed van maken. Dan kan een lokale gebruiker zelf wel de gebouwen vissen uit een nieuw OSM-BAG extract en die vervolgens uploaden. Zo kun je de verantwoordelijkheid voor het bijwerken toch lokaal houden. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
On 11-10-30 10:34 AM, Robert Elsenaar wrote: Deze aanpak zie ik ook wel zitten. Ik denk echter dat de werkwijze voor het importeren laagdrempelige gemaakt moet worden, zodat veel beetje ervaren lokale mappers het als een uitdaging zien om dit vergelijk te maken. Groet Robert Met vriendelijke groeten, Robert Elsenaar (Verzonden vanaf Mobile) Cartinus carti...@xs4all.nl schreef: On Sunday 30 October 2011 08:12:53 Frank Steggink wrote: On 11-10-30 12:52 AM, Stefan de Konink wrote: Dat je geen object ids nodig hebt kan kloppen als het systeem in 1 klap alle data laat importeren en daarmee het systeem laat bij houden welke data is ingevoerd en welke data mapt naar welk object. Of je verplicht iedereen een apart importaccount aan te maken en houdt een lijst van deze accounts bij. Dan kun je de data zonder teveel gedoe vervangen zodra er een mutatie is gedetecteerd, maar wanneer de versie van het object (en alle nodes) nog 1 is. Uiteraard met een importaccount. Het is dan wel van belang om oude data volledig te verwijderen en nieuwe data opnieuw te importeren, om het versienummer op 1 te houden. Wanneer de bestaande data al gewijzigd is, dan gaat dit niet meer op. Dit zal handmatig moeten gebeuren, om zeker te weten dat je geen user-contributed aanvullingen weggooit. Het maken van een importaccount voor imports is sowieso een best practice! Zie http://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_a ccount Jullie gaan allebei nog steeds uit van vergelijken van geupdate brondata met data in OSM door een programma. Daar heb ik het helemaal niet over. Je neemt BAG data van een beperkt gebied (je eigen buurt en misschien wat buurten eromheen of je eigen dorp). Dat converteer je naar OSM formaat. Dat geconverteerde bestand bewaar je! De volgende keer dat je de BAG data bekijkt maak je weer een bestand in OSM formaat met alleen BAG data. Dat vergelijk je met het vorige bestand met alleen BAG data. De verschillen tussen die twee ga je vervolgens _met de hand_ vergelijken met de data in OSM. Data vergelijken gaat bijvoorbeeld prima in JOSM met twee data-layers. Zolang de lokale mapper niet te veel hooi op z'n vork neemt moet dat prima te doen zijn. Dus: Hé, laat ik in m'n eentje de hele provincie Utrecht bijhouden. gaat nooit lukken. Utrecht Zuid-West en de noordrand van Nieuwegein is makkelijk bij te houden door één persoon. In de meeste plaatsen in Nederland hebben we niet zo'n groot overschot aan langdurig actieve mappers dat we elkaar voor de voeten zouden lopen met deze aanpak. -- m.v.g., Cartinus Ik ga er niet van uit dat de vergelijking geautomatiseerd gebeurt. Ik beschrijf alleen hoe je de vergelijking zelf doet, niet waarmee. In JOSM kun je ook zoeken op version:1. Een bepaald deel zou automatisch kunnen gebeuren (niet verplicht), maar het andere deel zeker niet. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OT: topospelletje Grontmij
Robert, Beetje kwestie van logisch nadenken :) De voetbalstadions ging nog wel, maar de attracties, musea en kastelen gingen slecht. Als ik per categorie 2 goed had, was dat veel. De zendmasten en watertorens daarentegen zijn weer een makkie, omdat meestal de plaats erbij vermeld wordt ;) Frank On 11-08-16 07:44 PM, Robert Elsenaar wrote: Frank, Ik vind dat onwijs knap van je. De plaatsen en de Grondmij vestigingen gingen nog wel, maar over de stadions en de attracties struikel ik voortdurend. Niet alleen topografische kennis, maar ook algemene kennis is hierbij van groot belang. En die ik kennelijk bij jouw erg breed. Vraagje, Weet jij bijvoorbeeld te vertellen waar visstek De Baars en De lage Raap liggen? Tja, dat is het nu met algemene kennis Je moet het maar net weten en er moet maar net je interesse liggen. Die laatste twee plekken ken ik wel, maar die vroegen ze niet. :-( Maar wie heeft er nu interesse in voetbal of pretparken . ;-) maar nogmaals sjappooo groet Robert -Oorspronkelijk bericht- From: Frank Steggink Sent: Monday, August 15, 2011 10:19 PM To: OpenStreetMap NL discussion list Subject: [OSM-talk-nl] OT: topospelletje Grontmij Hoi, Omdat de lijst in een zomerdip/-recessie verkeert, ga ik hem maar wat opleuken. De Grontmij heeft een spelletje [1] online gezet om je topokennis te testen. Wel jammer dat het in Firefox niet werkt, maar gelukkig nog wel in Chrome, dus meende ik de OSM-eer hoog te moeten houden. En niet geheel zonder succes [2] :) Groeten, Frank [1] http://www.gissenwaarhetis.nl http://www.gissenwaarhetis.nl/ [2] http://imageshack.us/photo/my-images/716/spelletjegrontmij.png/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl --- Tekst ingevoegd door Panda GP 2011: Als het hier gaat om een ongevraagde e-mail (SPAM), klik dan op de volgende link om de e-mail te herclasseren: http://localhost:6083/Panda?ID=pav_8494SPAM=truepath=C:\Windows\system32\config\systemprofile\AppData\Local\Panda%20Security\Panda%20Global%20Protection%202011\AntiSpam --- ___ 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] OT: topospelletje Grontmij
Hoi, Omdat de lijst in een zomerdip/-recessie verkeert, ga ik hem maar wat opleuken. De Grontmij heeft een spelletje [1] online gezet om je topokennis te testen. Wel jammer dat het in Firefox niet werkt, maar gelukkig nog wel in Chrome, dus meende ik de OSM-eer hoog te moeten houden. En niet geheel zonder succes [2] :) Groeten, Frank [1] http://www.gissenwaarhetis.nl http://www.gissenwaarhetis.nl/ [2] http://imageshack.us/photo/my-images/716/spelletjegrontmij.png/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fwd: European urban landuse vector data
In Canada wordt data geïmporteerd van de topografische dienst (CITS, Centre d'Information Topographique à Sherbrooke) die onder National Resources Canada (NRCan) valt. Deze data, Canvec, valt in het publieke domein. Deze dienst heeft zelfs mankracht en een FTP-server met voorgeconverteerde OSM-data ter beschikking gesteld. O.a. Daniel Bégin is een medewerker van NRCan. Meer informatie: http://wiki.openstreetmap.org/wiki/Canvec . Een nadeel is wel dat de Canvec data op sommige plekken flink verouderd is, ook in gebieden met een hogere bevolkingsconcentratie. De wegdata in Canvec is wel actueel. In het verleden werd ook een andere dataset van NRCan/CITS geïmporteerd, geheten Geobase. Dit was alleen wegdata. Groeten, Frank On 11-06-26 07:35 PM, Martijn van Exel wrote: Nee da's een Nederlands ding, maar er zijn wel andere landen met vergelijkbare import-projecten. Frankrijk importeert bijvoorbeeld veel overheidsdata. Canada vziw ook...(Frank?) Martijn 2011/6/26 Robert Elsenaarrob...@elsenaar.info: Een kort vraagje naar aanleiding van dit onderwerp. Zijn wij het enige land met 3dshapes? Of zijn ze in andere landen ook in dat gelukkige bezit? groet Robert -Oorspronkelijk bericht- From: Martijn van Exel Sent: Thursday, June 23, 2011 10:23 AM To: OpenStreetMap NL discussion list Subject: Re: [OSM-talk-nl] Fwd: European urban landuse vector data Hoi, Ik heb de shapefiles gedownload en een SLD voor geoserver gemaakt[1]. Als iemand ergens een publieke instantie van Geoserver heeft draaien dan heb je het zo online. Martijn [1] http://www.mvexel.dds.nl/osm/ On Tue, Jun 21, 2011 at 10:30 PM, Frank Stegginkstegg...@steggink.org wrote: Hoi, Zie mijn onderstaande post naar de imports lijst. Deze data voegt m.i. niet zoveel toe aan Nederland, aangezien de landuse nagenoeg compleet is, maar we zouden wel wat hiervan kunnen gebruiken om de residential en industrial gebieden te upgraden. De data heb ik nog niet in detail bekeken, maar het moet geen punt zijn om de data te herprojecteren en converteren naar OSM. Wellicht moeten we nog shapes gaan mergen (evt. met een kleine buffer), zodat er aaneengesloten gebieden ontstaan. Zie de bijgesloten PDF's in de datasets voor een eerste blik. Hoe denken jullie hierover? Groeten, Frank Original Message Subject:[Imports] European urban landuse vector data Date: Tue, 21 Jun 2011 22:23:46 +0200 From: Frank Stegginkstegg...@steggink.org To: impo...@openstreetmap.orgimpo...@openstreetmap.org Hi, I just noticed this post about European urban landuse vector data: http://blog.weogeo.com/2011/06/21/data-blog-european-urban-land-use-vectors/ It might be interesting for local communities within the EU who are seeking to improve landuse data in OSM in their area. This data can be downloaded here: http://www.eea.europa.eu/data-and-maps/data/urban-atlas The license seems to be compatible with CC-BY-SA or the ODbL, as long as the source is attributed: Rights: EEA standard re-use policy: unless otherwise indicated, re-use of content on the EEA website for commercial or non-commercial purposes is permitted free of charge, provided that the source is acknowledged (http://www.eea.europa.eu/legal/copyright). Copyright holder: Directorate-General Enterprise and Industry. However, before anyone proceeds importing this in OSM, it might be better to check with the EEA if their license is indeed compatible. And of course it is _always_ a good idea to check with your fellow local community members first, to see if this really adds value to OSM! Regards, Frank ___ Imports mailing list impo...@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl -- martijn van exel schaaltreinen.nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl --- Tekst ingevoegd door Panda GP 2011: Als het hier gaat om een ongevraagde e-mail (SPAM), klik dan op de volgende link om de e-mail te herclasseren: http://localhost:6083/Panda?ID=pav_6944SPAM=truepath=C:\Windows\system32\config\systemprofile\AppData\Local\Panda%20Security\Panda%20Global%20Protection%202011\AntiSpam --- ___ 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] 3D shape import
On 11-06-26 08:09 PM, Peter Peterse wrote: Hallo, weet iemand wat de status is van de 3Dshape import? Rond Rotterdam lijkt er nog een heel stuk te missen. Is hier een reden voor? Groeten, Peter ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Dag Peter, Aan de import van de 3dShapes landuse data is door verschillende mensen meegeholpen. Op een gegeven moment hebben Theun, Lennard (Ldp) en ik het resterende deel te verdelen. Lennard is verantwoordelijk voor het deel rond Rotterdam, maar heeft zich de laatste maanden op andere zaken gericht, o.a. de Mapnik stylesheet. Hij kan een beter antwoord geven wanneer hij verwacht dit deel af te ronden. Hij zal het ongetwijfeld afronden, maar hij heeft vorig jaar ook al veel tijd besteed aan de 3dShapes gebouwen import. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Fwd: European urban landuse vector data
Hoi, Zie mijn onderstaande post naar de imports lijst. Deze data voegt m.i. niet zoveel toe aan Nederland, aangezien de landuse nagenoeg compleet is, maar we zouden wel wat hiervan kunnen gebruiken om de residential en industrial gebieden te upgraden. De data heb ik nog niet in detail bekeken, maar het moet geen punt zijn om de data te herprojecteren en converteren naar OSM. Wellicht moeten we nog shapes gaan mergen (evt. met een kleine buffer), zodat er aaneengesloten gebieden ontstaan. Zie de bijgesloten PDF's in de datasets voor een eerste blik. Hoe denken jullie hierover? Groeten, Frank Original Message Subject:[Imports] European urban landuse vector data Date: Tue, 21 Jun 2011 22:23:46 +0200 From: Frank Steggink stegg...@steggink.org To: impo...@openstreetmap.org impo...@openstreetmap.org Hi, I just noticed this post about European urban landuse vector data: http://blog.weogeo.com/2011/06/21/data-blog-european-urban-land-use-vectors/ It might be interesting for local communities within the EU who are seeking to improve landuse data in OSM in their area. This data can be downloaded here: http://www.eea.europa.eu/data-and-maps/data/urban-atlas The license seems to be compatible with CC-BY-SA or the ODbL, as long as the source is attributed: Rights: EEA standard re-use policy: unless otherwise indicated, re-use of content on the EEA website for commercial or non-commercial purposes is permitted free of charge, provided that the source is acknowledged (http://www.eea.europa.eu/legal/copyright). Copyright holder: Directorate-General Enterprise and Industry. However, before anyone proceeds importing this in OSM, it might be better to check with the EEA if their license is indeed compatible. And of course it is _always_ a good idea to check with your fellow local community members first, to see if this really adds value to OSM! Regards, Frank ___ Imports mailing list impo...@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] ODbL fase 4 aanstaande zondag
Gert, Jij wilt een argument voor de ODbL en tegen de CC? CC is bedoeld als licentie voor zaken waarop _auteursrecht_ berust. Dat geldt niet voor _data_, aangezien hier geen _creatieve_ inspanning geleverd hoeft te worden. (Vandaar 'creative' in Creative Commons). De huidige situatie betekent dus dat iedereen die er zin in heeft een graai kan doen in OSM en de data kan gebruiken _zonder_ hiervoor verantwoording hoeft af te leggen, of zich ergens aan hoeft te houden. Voor hen is de CC niets anders dan iets om een bepaald deel van zijn lichaam mee af te vegen, voor wat data betreft. Uiteraard geldt dit niet als er data creatief is toegevoegd, d.w.z. easter-eggs. Dat is de enige manier om auteursrechtschenders te kunnen betrappen en er wat aan te doen. Ik vind het stuitend als zou blijken als hier op grote schaal (en ook op kleine schaal) sprake van zou zijn in OSM. Het doel is juist om de situatie waarheidsgetrouw vast te leggen. Het doet afbreuk aan de database. Het tagging schema valt hier m.i. niet onder, want dat is ook gericht op de feitelijke beschrijving van de situatie. Bovenstaande geldt alleen alleen in jurisdicties waarin feitelijke data niet als een creatief werk wordt gezien, waaronder de EU. In de EU en andere jurisdicties (niet in de VS, vziw) bestaat wel het databankenrecht. De ODbL is ervoor geschreven om duidelijk te maken dat de OSM data hieronder hoort te vallen. Dan is er tenminste een contract, waar de partij die een extract uit OSM haalt zich aan dient te houden. Dit hele verhaal staat los van PD. Als jij PD zo belangrijk vindt, en zelfs vindt dat OSM maar PD moet worden, wat maakt het jou dan uit dat de OSMF probeert de ODbL in te voeren, met daaraan de Contributor Terms om een zekere mate van vrijheid in de toekomst te garanderen? OK, het is niet helemaal wat jij wilt, maar het is in ieder geval een stap in de richting, een stap die toekomstvast is. Ik zie jou tegenstem puur als een politieke stem omdat iets niet helemaal gaat zoals het jou zint. Zelf ben ik ook pro-PD, en dat heb ik ook aangevinkt. Voor mij was dat juist dé reden om te denken dat die CT mij niet zo boeit. Als iemand anders mijn data wil hebben, be my guest. Verder vind ik ook dat, ondanks dat de tekst redelijk zwaar op de maag valt, er voldoende waarborgen in de CT zitten dat de OSM-data niet plotsklaps in verkeerde handen komt te vallen, of onder een gesloten licentie wordt geschoven. Ik vind de vergelijking met de huidige politieke situatie redelijk ver gaan. Dat slaat nergens op. Er zijn in OSM geen politieke partijen, en verder heeft OSM lang niet zo'n impact op het dagelijkse leven als onze volksvertegenwoordiging (alhoewel ik mijzelf niet vind vertegenwoordigd). Als jij, en andere tegenstanders, graag zou hebben gezien dat de zaken anders waren, dan hadden jullie je beter moeten organiseren. Voor wat ik proef in de eindeloze discussies, is dat jullie kamp feitelijk een kruiwagen vol kikkers is. De een wil alleen pro-PD, terwijl de ander absoluut niet wil afwijken van CC-BY-SA? Hoe kun je dan een vuist vormen? Juist, dat gaat niet. Verder weet je ook dat, als je zo politiek geëngageerd bent, dat 90% van de mensen mak stemvee is. Die zijn helemaal niet in de discussie geïnteresseerd, maar hopen alleen dat de trein blijft rollen (ofwel dat de beschikbaarheid van OSM-data in de toekomst blijft gewaarborgd). Als de OSMF in het theoretische geval zou voorstellen om een veel beperktere licentie te presenteren, moet je dan eens opletten. Dan komt een deel daarvan ook wel in actie. Ach, ik laat het hierbij zitten. Het is duidelijk dat jij de hakken in het zand zet en geenszins van plan bent om je mening bij te stellen. Ik wil nog wel even zeggen dat ik niet blij ben met de gang van zaken. Ik vind, evenals jij, dat er sprake is van verwarring en twijfel, maar m.i. is die juist door het anti-ODbL/CT kamp gezaaid. Groeten, Frank On 11-06-17 08:28 PM, ce-test, qualified testing bv - Gert Gremmen wrote: Dank je Henk. Er is een fundamenteel verschil van appreciatie met de gang van zaken tussen ons. Jij ziet de zaken vanuit het perspectief van het resultaat (voor OSM). Ik zie het vanuit de gang van zaken voor de community. Het huidige OSMF is dusdanig pragmatisch dat het werkelijk elk principe overboord zou gooien als daarmee een bepaald resultaat zou kunnen worden bereikt. Wat dat ook zou kunnen zijn. Vergelijk het in NL met de samenwerking van VVD /CDA met Geert Wilders. Het resultaat is niet eens zou erg, maar de wijze waarop tart elk gevoel voor rechtvaardigheid en respect. Terug naar OSM en de manier waarop CT/ODBL ons zijn opgedrongen. Kijk nu eens naar elke publicatie over de nieuwe licentie. Werkelijk overal wordt alleen maar gepoogd aan te geven hoe noodzakelijk dat is zonder enig argument behalve: “Bedrijven en instellingen die graag OSM data willen gebruiken, maar daarvan afzien vanwege de CC-licentie. Dit omdat de definitie
Re: [OSM-talk-nl] ODbL fase 4 aanstaande zondag
Gert, Ik ga toch maar happen. Zie inline. Frank On 11-06-17 08:51 PM, ce-test, qualified testing bv - Gert Gremmen wrote: Oh ja henk je vroeg om een verklarinen Zie inline *Van:*Henk Hoff [mailto:toffeh...@gmail.com] *Verzonden:* vrijdag 17 juni 2011 19:08 *Aan:* OpenStreetMap NL discussion list *Onderwerp:* Re: [OSM-talk-nl] ODbL fase 4 aanstaande zondag Gert, Ik vind het erg jammer dat je niet akkoord gaat met de Contributor Terms van Openstreetmap. Temeer ik nu je argumentatie lees. Ik neem toch even de vrijheid om hierop te reageren. Zie inline. 2011/6/16 ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl mailto:g.grem...@cetest.nl Ik vindt een nieuwe licentie onnodig omdat -we deze maar ook een andere licentie niet kunnen handhaven Verklaar. Dit snap ik niet. Zeer waarschijnlijk ligt jouw bezwaar ook bij de huidige CC-BY-SA licentie Inderdaad, alleen een commerciële organisatie met een duidelijk verdienmodel heeft het geld om een licentie te handhaven. Dat geld hebben we niet dus is ODBL alleen maar een speeltje voorde regelneven onder ons. Vandaar mijn inzet voor PD. [FS] Misschien moet het handhaven ook maar worden gecrowdsourced. De OSMF kan wel donaties / leden gebruiken. Je bent van harte welkom ;) OSM is te omvangrijk om een ongeleid projectiel te zijn. Vroeg of laat hebben die de neiging om neer te storten, dus ben ik allang blij dat er een stel regelneven is opgestaan om dit te voorkomen. Als die er niet zouden zijn, en er is helemaal geen structuur / richting in OSM, dan zou ik me wel drie keer hebben bedacht om mijn kostbare tijd daarin te steken! -er nooit problemen zijn geweest met cc-by-sa Helaas. Ik kom net weer van een business-conferentie af. Er diverse bedrijven/instellingen die graag OSM data willen gebruiken, maar daarvan afzien vanwege de CC-licentie. Dit omdat de definitie van afgeleid werk voor hun niet werkt. De ODbL concentreert zich op de data en daarmee kan men veelal wel mee uit de voeten. Business conferentie, wat doe je daar eigenlijk Henk. OSM gaat niet over business maar over open data. Daar hoort je focus te liggen. Je bent daar gewoon ingepakt. Heb je één argument behalve “niet werk” en “uit de voeten” [FS] De bekendheid vergroten van OSM? Mag het alleen door niet-zakelijke gebruikers worden gebruikt? De huidige licentie is notabene CC-BY-SA, en niet CC-BY-NC-SA. -ik eigenlijk wil dat OSM PD wordt, of liever helemaal niks Dat je persoonlijke mening. Maar als dat een reden is, waarom ben je uberhaupt bij OSM gekomen, gezien de huidige CC-BY-SA licentie? Wist ik veel wat CC-BY-SA was, ik ging voor de kaart ! Bovendien was de tendens veel meer PD like. [FS] Die tendens is me nooit zo opgevallen. Sommigen wel, maar ik geloof dat de meerderheid dit niet wil (en een veel grotere meerderheid het niet kan schelen). Overigens ben ik wel erg benieuwd naar de PD support, en ik vind dat de OSMF deze data moet vrijgeven. Er is geen enkele reden om dit verborgen te houden! -ik niet acceptabel vindt dat 0.1 % van OSM (OSMF) de community in gijzeling neem Verklaar. Er zijn verschillende polls en stemmingen geweest. Zowel onder de OSMF leden als ook onder de brede community. In alle gevallen was daar een duidelijke meerderheid voor de ingeslagen weg. Wanneer we nu naar de acceptatie van de CT kijken, kan ik constateren dat ruim 98% heeft ingestemd. Iets meer dan 1% heeft geweigerd (waaronder dus jij). Hoezo gijzeling? Als ik morgen met 12 andere leden zeg dat OSM voortaan PD wordt heb ik dan de mogelijkheid om leden uit te sluiten die niet accoord gaan ? Heb ik de macht over de user accounts ? Heb ik de domeinnaam ? [FS] Alsof de OSMF over één nacht ijs gaat. Dit proces duurt al een jaar of 6. Als iemand een beter alternatief zou hebben, dan zou dit zeker opgepakt zijn. Dat jij het hier niet mee eens bent, wil niet zeggen dat dat ook voor de andere 399.999+ gebruikers geldt. -er nooit een moment geweest is dat OSM open stond voor iets anders dan ODBL Er zijn diverse opties bekeken. De ODbL is momenteel de beste keuze. CC-by-SA 3.0 ? PD ? wat is daar eigenlijk mis mee ? [FS] CC-BY-SA: zie andere e-mail. PD: een stap te ver voor velen (wederom: meer informatie van de OSMF gewenst). -de licentie onnodig autoritair, formeel en juridisch geformuleerd is Kijk eens naar de officiele tekst van CC-BY-SA: http://creativecommons.org/licenses/by-sa/2.0/legalcode Dat is een CC-BY-SA _licentie_ vgl de ODBL _licentie_ geen CT die ik noem. [FS] Jij hebt het over de licentie en noemt niet de CT specifiek. -ik een hekel heb om juridisch te worden gebonden voor dingen die IK kado geef (stel je kan schilderen en geeft een schilderij aan iemand kado, zou jij accepteren dat die iemand daar een onherroepelijke licentie bij wil afsluiten en anders het schilderij weggooit ?) Prima. Maar wat is het verschil met de huidige situatie? De CT [FS]
Re: [OSM-talk-nl] BAG
On 11-06-04 10:06 AM, Floris Looijesteijn wrote: Aangezien er dus al BAG data in OSM zit neem ik aan dat er toch goed naar dat hergebruik gekeken is? Gr, Floris PS. is er nog steeds behoefte om bij elkaar te gaan zitten, of is deze thread net zo handig? Hoi Floris, De BAG data van Nijmegen is een iets ander verhaal. De gemeente is zelf bronhouder, dus hoe dan ook(*) bezitten zij de rechten op de data. Frank (*) afgezien van/ondanks (het gebrek aan) copyright op bestaande data, databankrecht, WOB-baarheid, etc. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Quoting Martijn van Exel m...@rtijn.org: In mijn beleving was het altijd zo dat er twee soorten mappers bestaan: de mensen die van opvullen houden en de mensen die van aanvullen houden. Dus de mappers die graag pionieren op een blanco kaart en de mappers die liever in een al wat gevulde kaart werken. Maar volgens mij is dat een te grote versimpeling van de werkelijkheid. Ik val zelf bijvoorbeeld al meteen niet in een van mijn eigen categorieen... Er is in mijn beleving nog een derde categorie mappers, namelijk mensen die graag over mappen praten. Dat verklaart m.i. jouw constatering over jezelf. j/k ;) Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Quoting Martijn van Exel m...@rtijn.org: Gert et al, 2011/6/1 ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl: Wat in de hele OSM strategy ontbreekt is een update strategie. Deze BAG data heeft inderdaad de potentie om de hele community te overspoelen met update werk . Aan de andere kant wordt de BAG data ook bijgewerkt door de overheid. Als we een geautomatiseerd systeem hadden om updates in OSM te laden, dan zou deze hoeveelheid niet zo erg zijn. (overigens : is het echt zoveel meer dan de 3d importen?) Op kleine schaal zie je dat met bijvoorbeeld de fietsroutes. Als er iets veranderd is het maar de vraag of dat door iemand van ons wordt opgemerkt. Daar zouden we ons de komende jaren op moeten richten: Hoe houden we de data up-to-date ? Dit was ook mijn zorg. Niet alleen voor de updates op zich, wat al een hoop werk is (ze komen maandelijks uit) maar ook hoe om te gaan met 'echte' edits door de community op gebouwen, zie mijn eerdere mail. Dit speelde met AND niet omdat het een eenmalige update was, en voor 3DShapes misschien in mindere mate omdat veel van het grondgebruik sowieso niet snel door de community in kaart zou worden gebracht: moeilijk en lage prioriteit, maar het ziet er nu wel fraai uit. Maar ook deze data veroudert op den duur. We moeten wat mij betreft ook onder ogen zien dat de BAG misschien niet per se in de OSM-database zou hoeven te worden geimporteerd. Het kan ook als afzonderlijke laag worden weergegeven. Importeren moet niet dogmatisch worden. Het is niet van: er is vrije data, *dus* het moet in OSM. Mee eens. Deze trend is ook enige tijd op talk waar te nemen. Als ik deze kennis ca 1 1/2 jaar geleden had, weet ik niet of ik mij nog wel met volle overgave op de landuse van 3dShapes gestort zou hebben... Waar bijna iedereen het wel over eens is, is dat het community-aspect van OSM veel belangrijker is dan het zijn van een open data-warehouse. Dat betekent ook dat het minder noodzakelijk is om na te denken over een update-strategie. Dat zal altijd lastig geworden. Nieuwe gebruikers zullen zich niks aantrekken van ID's. Het is erg makkelijk om ze te vernaggelen met de huidige editors (bijv. door knippen en mergen van shapes). Niet de schuld van de editors, maar de identificatie van een objectje in OSM is de geometrie zelf (en in mindere mate het OSM ID) en niet een extern ID wat als attribuut eraan hangt. Dat gaat dus conflicten opleveren met systemen die wel ID-gebaseerd zijn, zoals de BAG. Zelfs het OSM ID kan gaan wandelen in de loop van de tijd. Het is geen permanent gegeven. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Quoting ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl: Wat in de hele OSM strategy ontbreekt is een update strategie. Deze BAG data heeft inderdaad de potentie om de hele community te overspoelen met update werk . Aan de andere kant wordt de BAG data ook bijgewerkt door de overheid. Als we een geautomatiseerd systeem hadden om updates in OSM te laden, dan zou deze hoeveelheid niet zo erg zijn. (overigens : is het echt zoveel meer dan de 3d importen?) Op kleine schaal zie je dat met bijvoorbeeld de fietsroutes. Als er iets veranderd is het maar de vraag of dat door iemand van ons wordt opgemerkt. Daar zouden we ons de komende jaren op moeten richten: Hoe houden we de data up-to-date ? Er zijn tools waarmee je veranderingen beter kunt volgen, zoals OWL wat door Matt Amos is gemaakt. Hiermee kun je bijv. een RSS feed opvragen met de recente wijzigingen in het gebied. Het werkt beter dan het opvragen van de changes met een bounding box via de main OSM site. Wereldomvattende edits blijven buiten beschouwing, tenzij ze echt binnen het gebied zelf wijzigingen hebben. V.w.b. geautomatiseerd updaten: hier bestaat weerstand tegen en m.i. is dat terecht. Ik wil niet dat het BAG-updatebotje van H@ndigeH@rry OSM in mijn buurt gaat lopen verzieken. Niemand wil dat. De hoeveelheid werk van de initiële upload zal sowieso meer zijn dan de upload van de 3dShapes gebouwen. Dit omdat heel Nederland al voorzien is van gebouwen. Ook zijn gebruikers actief aan de slag gegaan met huisnummers toevoegen, etc. Ik heb dat in mijn wijk en een naburige wijk ook gedaan, in de verwachting dat bijv. de BAG niet geïmporteerd zou worden. Ergens moet je een grens trekken: je wilt als OSM community je niet constant gaan laven aan de (open) data-stroom van de overheid. Je moet je eerst afvragen of het nodig is en wat het oplevert. De BAG-data zou ons i.i.g. adresinformatie opleveren. Als we alleen dit kunnen extraheren, dan zal de import ook makkelijker gaan en voor minder conflicten zorgen. Door een ruimtelijke query erop los te laten, kun je ook gebieden uitsluiten die al zijn voorzien van huisnummers (en deze gebieden aan de mappers daarvan beschikbaar stellen). Eenzelfde werkwijze zou ook voor de footprints van de gebouwen aangehouden kunnen worden. Waar in OSM al gebouwen zitten, zou ook aan lokale mappers ter beschikking gesteld kunnen worden. Voor mij hoeven in OSM de gebouwen niet zo perfect in te zitten als in BAG, aangezien de meeste casual mappers niet met deze nauwkeurigheid werken ;) Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Quoting Vincent Zweije vinc...@zweije.nl: On Wed, Jun 01, 2011 at 04:22:05PM +0200, Jeroen Muris wrote: || De BAG wordt door iedere gemeente afzonderlijk bijgehouden (en via || XML berichten met een 'landelijke voorziening' uitgewisseld). Nu || kan het voorkomen dat een woonplaats aan, op, of over de grens van || een gemeente ligt; dan zal elke gemeenten die objecten (panden, || nummeraanduidingen, ...) in die woonplaats heeft de woonplaats in || haar administratie opnemen. Afhankelijk van hoe de BAG dan || bevraagd wordt kan één woonplaats dan meermalen voorkomen. Hee! Ik lees hieruit dat de gemeenten elkaar, dan wel een centrale BAG, up to date houden met (roffel) updates! Als we die nou kunnen krijgen? Dat zou wel eens heel nuttig kunnen zijn voor het up to date houden van onze BAG informatie, mochten we een BAG import of tussenbestand maken. We moeten ons dus als de wiedeweerga aansluiten bij de Landelijke Voorziening en zorgen dat we voor 1 juli de BAG van heel Nederland gratis binnen hebben. ;) Alle gemeenten zijn ondertussen aangesloten, dus de LV is gevuld. Zodra er duidelijkheid is over het hergebruik is van de BAG-data, kunnen we de nuttige delen hieruit importeren in OSM. Meer info: http://bag.vrom.nl/de_bag_gebruiken/vraag_en_antwoord#v8b26cdcfe276bdac8813e5709073a6c0 Martijn, Jeroen: weten jullie of deze FAQ nog actueel is? Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Quoting Lennard l...@xs4all.nl: On 1-6-2011 16:08, Jeroen Muris wrote: Trouwens, is die Nijmegen-import ergens gedocumenteerd? Ik kon op de wiki niks vinden. Nee, voor zover ik heb kunnen nagaan is die import nergens gedocumenteerd. De gebruiker 'nijmegen' was onbereikbaar. Ik heb daarna contact gehad met de gemeente Nijmegen. Zei zeiden: Neem voor verdere informatie eens contact op met Roeland Douma. Leest uiteraard (en hopelijk regelmatig) mee hier. Hij heeft de import uitgevoerd onder dat account. Een medewerker van de gemeente Nijmegen heeft zich aangemeld bij de OSM-groep in LinkedIn. Daarop heeft Roeland de stoute schoenen aangetrokken, een verzoek voor interessante data voor OSM bij hem neergelegd, en heeft hij de BAG-data gekregen. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Betr: Re: Uiterlijk van de kaart
Ik geloof dat de OpenCycleMap ook SRTM gebruikt, evt. aangevuld voor de gaten en boven 60 graden NB. De resolutie van de EEA DEM is 10x zo laag. Deze is 1x1 km, terwijl de versie van SRTM die publiek toegankelijk is een resolutie heeft van 3 arcseconds. In Nederland komt dat overeen met ca. 57x92.5 meter. Er is nog een andere DEM, namelijk de Aster GDEM [1], die claimt een resolutie te hebben van 30x30 meter, maar de data zit vol met onvolkomenheden. Er zit ook een grote verticale afwijking in, van min. 10 meter. Arnhem ligt volgens die DEM op zeeniveau ;) Groeten, Frank [1] http://www.gdem.aster.ersdac.or.jp/ On 11-05-13 04:33 PM, Martijn van Exel wrote: Ik meen me te herinneren dat dat ook SRTM is..? Er is er ook 1 van de EEA, weet niet of die compatible is met OSM qua licentie: http://www.eea.europa.eu/data-and-maps/data/digital-elevation-model-of-europe Ziet er trouwens ook niet gedetailleerder uit dan SRTM. Martijn 2011/5/13 dbuss...@goudappel.nl mailto:dbuss...@goudappel.nl Ik zie nu pas dat er inderdaad hoogtelijnen op de kaart staan. Weet iemand wat de oorspronkelijke bron is van de hoogtedata en of die in de osm-planetfile is ingelezen of bij het renderen extern opgehaald wordt? Wij gebruiken namelijk voor de fietsrouteplanner AHN-hoogtedata voor de zuidelijke provincies maar hebben bij het landelijk gaan hoogtedata onder een vrije licentie nodig. Op dit moment niets beters gevonden dan SRTM, maar wat ik op openstreetmap.org http://openstreetmap.org qua hoogtelijnen zie is veel beter. Groeten, Dirk Bussche ___ Talk-nl mailing list Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl -- Martijn van Exel http://about.me/mvexel ___ 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] hack weekend Essen
On 11-04-21 08:44 PM, Lennard wrote: On 21-4-2011 8:41, Martijn van Exel wrote: Ha allemaal, Van 10-12 juni is er een OSM hack weekend in Essen, net over de grens. Leuk! Dat is vlakbij mij. Ook vanuit Nederland goed te bereiken. Vanuit Roosendaal pak je de stoptrein naar Antwerpen. Na 7 minuten kun je dan uitstappen in Essen. Inderdaad nèt over de grens. :) Ik weet niet waar jullie het over hebben. Essen ligt gewoon in Nederland. Het is nl. een gehucht bij Groningen [1]. Wat we daar moeten zoeken, veel te ver weg... Frank [1] http://osm.org/go/0GXOHBYt?m ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
