Re: [OSM-talk-nl] Tagging laadpalen auto in Nederland
On 5/18/23 11:51, Hugo hölscher wrote: Is hier al eerder over gedacht, ik heb in deze mail list niets gevonden. De Nederlandse community is hier niet echt actief meer, de activiteit is tegenwoordig op het forum: https://community.openstreetmap.org/c/communities/nl/43 Mvg, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Letter to the OSM Community in The Netherlands
On 11/21/22 08:55, Diana-Ioana Danciu via Talk-nl wrote: Hello OSM community in The Netherlands, You'll reach more of the OSM community in the Netherlands via: https://community.openstreetmap.org/c/communities/nl/43 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] V3 to V4 Mapillary image id migration
You'll reach more member of the Dutch community via the forum: https://forum.openstreetmap.org/viewforum.php?id=12 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Milestones are public domain but not in OpenStreetMap
On 9/15/21 12:01 PM, dktue wrote: > Hello dutch openstreetmap community, You'll have much luch reaching the Dutch community on the forum: https://forum.openstreetmap.org/viewforum.php?id=12 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Importing trees in Utrecht
On 9/27/20 6:44 PM, Pieter van Mill via Talk-nl wrote: > If there are any comments I would love to hear them, More mappers are active on the forum, you'll get more feedback there. https://forum.openstreetmap.org/viewforum.php?id=12 Since you only talk about importing, also think about how the data will be updated. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Even voorstellen
Op het forum zijn meer mappers actief: https://forum.openstreetmap.org/viewtopic.php?id=151=9 Mvg, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG straatnamen (ook?) in OSM
On 4/14/20 5:08 PM, Richard Duivenvoorde wrote: > Is er dan een andere mogelijkheid om, gegeven een officieel adres of > straatnaam, een koppeling te maken met een OSM straat of pand? Op basis van de coordinaten in de BAG kan de node of way met dat adres in OSM gevonden worden, en op basis daarvan kan de dichtsbijzijnde straat met die naam gevonden bijvoorbeeld met een algoritme zoals geimplementeerd in de FixAddresses plugin: https://wiki.openstreetmap.org/wiki/JOSM/Plugins/FixAddresses De meeste mappers zijn actief op het forum, daar zal je vraag meer mensen berijken: https://forum.openstreetmap.org/viewforum.php?id=12 Mvg, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] Issues with diffs
On 05/09/2018 08:21 PM, Andrzej Kępys wrote: > OsmosisRuntimeException: The replication state doesn't contain a > timestamp property. > Any idea where can I post/report this? You need to get a different planet with all data, see: https://lists.openstreetmap.org/pipermail/dev/2018-May/030233.html Kind Regards, Bas ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Responding to vandalism
On 03/16/2017 06:13 PM, James wrote: > People can't even be bothered to review osmcha, you think people will want > to approve changesets? Eventually, yes. It will become part of a responsible and thriving local community. Debian managed to transition from a free-for-all (just mailing the project leader) to a new-maintainer process and sponsors in teams to assist new contributors. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Responding to vandalism
On 03/16/2017 05:30 PM, James wrote: > and maintainers privileges, would be determined by whom? Other maintainers? Yes, the local community grants that privilege. When the local community is dysfunctional there is the overriding authority of OSMF WGs like DWG. Like we have the Technical Commitee in Debian or General Resolutions (project wide votes). > Then you have whats going on on Wikipedia Fr where it's controlled by a > small group of close friends that refuse anything outside their norms, > which is bad. Wikipedia is not a model that one should choose to model, Linux distributions are a much better role model. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fixing broken multipolygons
On 03/03/2017 05:10 PM, m...@rtijn.org wrote: > Since the ‘self-intersecting’ challenge is now complete I featured the ‘Wrong > role’ challenge in MapRoulette. Happy fixing! Are there plans to make these challenges permanent or periodically re-introduce them when a new batch of issues has been prepared? These are very common issues that will be introduced by mappers in the future. Having Maproulette challeges to fix the issues also visualized by the OSMI Area maps is a great way to help fix these QA issues. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fixing broken multipolygons
On 02/21/2017 05:40 PM, Jochen Topf wrote: > Find all challenges and instructions here: > http://area.jochentopf.com/fixing.html My OCD complains about the typo before the challenge links, please do sed -i 's/Got to /Go to/g' fixing.html Also the Maproulette paragraph is no longer accurate now that more than one challenge has been created. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Luchtfoto's 2016 beschikbaar voor tracen in OSM
On 02/10/2017 07:33 PM, Maarten Deen wrote: > On 2017-02-10 12:09, Sebastiaan Couwenberg wrote: >> On 02/10/2017 11:58 AM, Maarten Deen wrote: >>> Hoe kun je deze beelden in JOSM krijgen? >> >> Via Imagery Preferences, en dan de WMS of WMTS toevoegen m.b.v. de URLs >> die op NGR staan. > > Er staan een flink aantal URLs op op die site en ik heb er ook veel van > geprobeerd, maar nog geen succes. Kun je wat uitgebreider zijn > misschien? Welke url moet ik exact nemen? Klik op de 'Luchtfoto 2016 25cm RGB open data' link die je vind op de NGR pagina uit Johans post, op die pagina staan een WMS & WMTS link. Als je daar niet uit komt, moet je Commodoortjes instructies voor noobies maar volgen: https://forum.openstreetmap.org/viewtopic.php?pid=631054#p631054 Als de CA store in Java actueel genoeg is hoef je het slechte advies om de HTTPS URL naar HTTP om te zetten niet te volgen. Mvg, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Luchtfoto's 2016 beschikbaar voor tracen in OSM
On 02/10/2017 11:58 AM, Maarten Deen wrote: > Hoe kun je deze beelden in JOSM krijgen? Via Imagery Preferences, en dan de WMS of WMTS toevoegen m.b.v. de URLs die op NGR staan. Mvg, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Update nieuwbouw in Aerdenhout
On 10/06/2016 11:53 AM, Hugo Holscher wrote: > In Aerdenhout bij de Gezina van de Molenlaan en Mies Noltenlaan > (http://www.openstreetmap.org/?mlat=52.36121=4.60237#map=19/52.36121/4.60237) > zijn nieuwe woningen gebouwd. > Ze zijn deels al sinds begin dit jaar bewoond. Ze staan echter nog niet op de kaart. > Ik kan me niet voorstellen dat er geen kadaster gegevens zijn (na 2 jaar). > Kan iemand nagaan of er iets mis is met de up-loads van de kadaster gegevens? In de BAG staan er al wel panden (met status in gebruik), zoek maar op de straatnamen in de BAGViewer: https://bagviewer.kadaster.nl/ Op het forum is een topic voor BAG update verzoeken: http://forum.openstreetmap.org/viewtopic.php?id=52973 Mvg, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] postkantoren in Nederland
On 09/11/2016 10:45 AM, Ronald Stroethoff wrote: > Op de website "http://overpass-turbo.eu; kan je zoeken op > "amenity"="post_office". > Er wordt dan gezocht in het dan geopende venster. > Ik was een beetje verrast door de hoeveelheid postkantoren in Nederland die > vervolgens zichtbaar werden. > Ik denk dat het geen goede indruk maakt als er nog zoveel postkantoren > zichtbaar zijn. > Hoe gaan we daarmee om? Gebruik de overpass resultaten als basis voor je surveys waarbij je on the ground controleerd wat er in plaats van het postkantoor is gekomen. Mvg, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] combinatie POI over winkel met adres (afkomstig uit BAG)
On 08/03/2016 09:40 PM, Ronald Stroethoff wrote: > Ik las enige tijd geleden een discussie over het intekenen van winkels als > POI. > Sommige mensen gaven toen aan dat ze de POI van een winkel combineerde met > het uit de BAG verkregen adres, ze zagen het als een voordeel dat de POI van > de winkel dan ook een adres aangaf. > Helaas blijkt dat dit oplettendheid vereist bij het verwijderen van gesloten > of verhuisde winkels. > Men kan dan namelijk niet De POI zomaar weggooien, men moet alleen de > gegevens van de winkels verwijderen en de rest laten staan. > Op deze locatie is dat denk ik vandaag niet goed gegaan: > http://www.openstreetmap.org/changeset/41208474#map=18/52.20496/4.39686 Dat is een veel voorkomend probleem, en op te lossen door de adressen in de BAG te vergelijken met die in OSM. Het niet afkorten van straatnamen is daarbij wel een complicerende factor. Zolang iedereen een account kan aanmaken en direct toegang krijgt tot de productie database zal de data in OSM altijd veel QA vereisen. Het onbedoeld slopen van OSM data is immers veel te eenvoudig. Mvg, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Uithoorn
On 07/25/2016 01:32 PM, Ante Wessels wrote: > Ik reed laatst het dorpje binnen waar ik geboren ben, Uithoorn, en merkte dat > de rondweg waar tientallen jaren over gepraat is warempel aangelegd is > (N201+). > > Hij staat als ontwerp in OSM. Nu heb ik al tien jaar geen OSM editor meer > gebruikt, dus als iemand anders de status wil veranderen, dank. De N201+ is al sinds 2014 klaar en in gebruik, zo ook in OSM. Waar zie je nog stukken N201+ in de oude staat? Mvg, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk] OSGeo-Live team needs help: Someone who looks after OSM data, tools and writes documentation is needed
Forwarded Message Subject: [Live-demo] OSGeo-Live team needs help: Someone who looks after OSM data, tools and writes documentation is needed Date: Sat, 11 Jun 2016 13:06:11 +0200 From: Astrid EmdeTo: Live Demo Hello OSM enthusiasts, this is a mail from the OSGeo-Live team [1]. OSGeo-Live is a linux based distribution of open source geospatial software which is handed out at conferences around the world, and used as the foundation for open source geospatial training courses. We use OSGeo-Live to teach enthusiasts how to create geospatial data with free tools. At the moment, we include an extract of OSM data, and how to use Mapnik, but we'd love to be doing a better job of promoting OSM which in turn should attract motivated geospatial people into the OSM community. The catch is that we need some help understanding OSM tools, and keeping these tools and docs up to date, which is where you (the OSM community) comes in. We are hoping to find one or two people who can help us write Application Overview [2] and 10-15 min Quickstart docs, and act as a point of contact to advise on OSM as we build each release. This is what we are looking for. Are you interested to help? It could be a single person or a team. And the OSGeo-Live team is also supporting, when help is needed. This is what you have to do - don't worry, it should not be too much work ;) * provide the up-to-date software every half a year when a new version of OSGeo-Live is coming out * check the documentation (Overview and Quickstart) -> is there anything to update * provide new up-to-date OSM data (f.e. for version 10.0 we will provide data from Bonn where FOSS4G 2016 will be in august) * provide a quickstart (tutorial to help people to get to know OSM and make the first steps) - this quickstart does not exist at the moment and has to be written * OSM covers data and OSM tools (like JOSM) which are not documented yet ** we only have a documentation for Mapnik http://live.osgeo.org/en/overview/mapnik_overview.html Are you interested? If yes - please let us know. (subscribe to the OSGeo-Live (Live-demo) mailing list [4] or write to astrid_e...@osgeo.org) Regards Astrid from OSGeo-Live PSC [1] http://live.osgeo.org [2] OSM Overview http://live.osgeo.org/en/overview/osm_dataset_overview.html [3] OSGeo-Live Dokumentation in the OSGeo wiki http://wiki.osgeo.org/wiki/Live_GIS_Disc [4] Live-demo mailing list https://lists.osgeo.org/mailman/listinfo/live-demo ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] BAG update
On 08-01-16 15:01, Éric Piel wrote: > Are there any recommended ways to update the BAG imported building data? > I had a look at these pages in the wiki, but they appear to not have > been updated for a while: > http://wiki.openstreetmap.org/wiki/BAGimport > http://wiki.openstreetmap.org/wiki/BAGimport_via_ODS_plugin > > I'm fairly experienced with JOSM, and I have done some building imports > previously. > > Thanks for any pointer or help! The new version is JOSM plugin is not widely available yet, in the mean time we coordinate BAG updates on the forum: http://forum.openstreetmap.org/viewtopic.php?id=52973 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] Tile Server manual build 15.10 troubleshooting
On 03-01-16 19:35, Skyler F wrote: > So is there another way I can install this without the configure and > autogen? Use the packages included in Ubuntu itself. wily includes osm2pgsql 0.88.1 which is current enough. https://launchpad.net/ubuntu/+source/osm2pgsql Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tile Server manual build 15.10 troubleshooting
On 03-01-16 17:48, Graham Jones wrote: > if you type "sudo apt-cache search libtiff" it lists all the packages that > are available with 'libtiff' in the title. On my system it lists > libtiff5-dev, so I would suggest installing that. Just install libtiff-dev, it is the virtual package provided by both libtiff4-dev & libtiff5-dev, it will pull in the relevant libtiffN-dev package for the distribution in question. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tile Server manual build 15.10 troubleshooting
On 03-01-16 18:27, Skyler F wrote: >> sudo apt-get install postgresql postgresql-contrib postgis >> postgresql-9.3-postgis-2.1 > > Reading package lists... Done >> Building dependency tree >> Reading state information... Done >> E: Unable to locate package postgresql-9.3-postgis-2.1 Ubuntu vivid and later have postgresql-9.4 for which the postgis packages is: postgresql-9.4-postgis-2.1 https://launchpad.net/ubuntu/+source/postgis Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Call For papers Geospatial devroom @FOSDEM 2016
Forwarded Message Subject: [OSGeo-Discuss] Call For papers Geospatial devroom @FOSDEM 2016 Date: Mon, 2 Nov 2015 08:22:03 +0100 From: Johan Van de WauwTo: OSGeo Discussions , LocationTech Working Group discussion list Please forward! FOSDEM is a free and non-commercial event bringing together about 5000 developers in Brussels, Belgium. The goal is to provide open source software developers and communities a place to meet and share thoughts. The participation is free of charge, although donations are welcome. The next edition will take place the last weekend ofJanuary 30 - 31 2016. This year for the second time there will be a Geospatial devroomon Sunday 31/1/2016, organised by members of the OSGeo, Locationtech and OpenStreetMap communities. Geospatial technology is becoming rapidly mainstream. The idea underpinning the geospatial devroom is bringing together developers with different backgrounds to disclosethe opportunities offered by cutting-edge open source geospatial technologies. Due to the success of last years devroom, a Belgium local chapter of OSGeo, OSGeo.be was founded, and is now taking part of the organisation of the devroom as driving community. The Geospatial devroom is the place to talk about the state of the art of open, geo-related data, free and open source geospatial software and its ecosystem. This includes standards and tools, e.g. spatial databases, online mapping tools, geospatial services, used for collecting, storing, delivering, analysing, and visualizing geodata. We welcome submissions about: * Web and desktop GIS applications * Interoperable geospatial web services and specifications * Collection of data using sensors/drones/satellites * Open hardware for geospatial applications * Geo-analytic algorithms/libraries * Geospatial extensions for classical databases (indexes, operations) and dedicated databases * Collaborative editing/versioning of geodata * Big geodata, scalable GIS applications * Volunteered Geograpic information - Crowdsourced data HOW TO SUBMIT YOUR PROPOSAL FOR A TALK Are you thrilled to present your work to other open source developers? Would you like to run a discussion? Any other ideas? Please submit your proposal using the Pentabarf event planning tool at: https://penta.fosdem.org/submission/FOSDEM16 Make sure to select the 'Geospatial devroom' as 'Track'. Please, specify in the notes if you prefer for your presentation either a short timeslot (lightning talks ~10 minutes) or along timeslot (20 minutes presentation + discussion). However, note that time slots are indicative and will be assigned according to the needs of the session. The DEADLINE for submissions is Tuesday **1st December 2015**. Notification of acceptance will be sent to the Authors by Friday 11/12/2015 at the latest. Should you have any questions, please do not hesitate to get in touch with the organisers of the devroom at fosdem-geospat...@gisky.be! Johan Van de Wauw Margherita Di Leo Astrid Emde Anne Ghisla Martin Hammitzsch Andy Petrella Dirk Frigne Olivier Courtin Thomas Gratier ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] open question about boundaries sharing nodes with ways or nodes
On 14-10-15 09:49, Badita Florin wrote: > Our task is to delete all the existing admin_level=6 boundaries and start > fresh, but this seems much more things needs to happen before you do this. Don't delete the existing boundaries, update them to match the new reality using the ReplaceGeometry feature in JOSM for example. When the data for shared nodes is available, it will disconnect the other ways from the boundary way being replaced leaving the other ways as they were. > This way is a highway and at the same time is part of the relation of a > boundary. This seems invalid since it merges two types of features on the > same way instead of keeping a logical separation between two different > things. Is this a valid way? What if the highway is modified ? since the > highway is not a legal boundary and just happens to overlap the real > boundary, so if the highway is changed for any reason, it will modify the > boundary along with it. So what's the valid thing to do here? Duplicate the > way to save the highway way and keep a way for the boundary separated?, In the Americas people seem to be fond of using natural features as boundary ways, in The Netherlands we keep these strictly separate. The administrative boundary may follow a river for example, but these are two distinct features that happen to share a similar geometry. At the highest zoom level in JOSM you'll see that the river way doesn't share the nodes from the boundary and if they do that's an issue to be fixed by disconnecting the shared node(s), each feature has its own way and nodes. Because natural features tend to change when the administrative boundaries do not, we have to keep them separate. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] FOSDEM 2016, 30th and 31st January 2016, Brussels
On 13-10-15 21:04, Stefan Keller wrote: > There's a upcoming deadline for first batch of main track proposals: > 16 October 2015. > And there's a Proposal for a Geospatial devroomː > https://titanpad.com/VCAR6DZfHG I'd love to see a bigger OSM presence in the Geospatial track, OSM was a bit under-represented last year. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] "Enclosing feature" on osm.org broken ?
On 12-09-15 10:39, Marc Gemis wrote: > I recently saw two independent reports [1][2] from people that complain > that the list of "Enclosing Features" is returning a number of > North-African towns for features in The Netherlands. > > An example is when you first go to [3] and then click with the question > mark on the cycle road "Titus Brandsmalaan" > > I checked the boundaries of those administrative units in e.g. Algeria and > did not notice anything suspicious. They were unaltered for 9 months or > longer. > > Anyone knows what is going on ? I suspect the unclosed boundary rings in the neighborhood Souk El Tenine are part of the problem. See OSMI: http://tools.geofabrik.de/osmi/?view=multipolygon=5.33976=52.15100=8=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,ways,role_markers,way_end_nodes,way_nodes Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015
De fouten heb ik aan dit bericht toegevoegd. Het zijn fouten in 179 adressen die voorkomen uit maar 7 fouten in straatnamen. Wie kan dat doorzetten? Je bent zelf de meeste aangewezen persoon om deze fouten terug te melden. https://www.kadaster.nl/web/formulier/BAG-formulieren/BAG-terugmeldingsformulier.htm Lees ook het BAG processenhandboek waarin de verschillende velden beschreven zijn, zo kan je duidelijk geformuleerde terugmeldingen doen. http://www.kadaster.nl/web/artikel/download/BAG-processenhandboek-2013-1.htm Mvg, Bas ___ 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.
Wat ik een hele leuke toevoeging van Rijkswaterstaat zou vinden, en volgens mij sluit dit aan op wat Hendrikklaas bedoelt, is wanneer terreinen die normaal niet publiek toegankelijk zijn op afspraak open zouden kunnen worden gesteld voor geinteresseerde openstreetmappers zoals Hendrikklaas. Zou dat eventueel tot de mogelijkheden behoren? Het zou een leuke aanvulling en prikkel kunnen zijn! Ik wil dit voorstel graag onderstrepen. Nederlandse Mapping Parties waarbij daadwerkelijk gemapped wordt zijn alweer een flinke tijd geleden, het gezamelijk mappen van RWS terreinen lijkt mij een geweldige gelegenheid om met OSM mappers en RWS personeel samen te werken. Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG vs On-The-Ground (Was: Groenlandsekade/Groenlandse Kade, Vinkeveen)
On 05/31/2015 12:14 PM, Colin Smale wrote: Ook in Woerden doet zich dit voor. Botnische golf, Middelandse zee, Finse golf hebben een afwijking tussen de schrijfwijze volgens BAG en de schrijfwijze op de borden ter plaatse. De conventie in Nederland is dat alle woorden in een straatnaam een hoofdletter krijgen, dus beschouw ik in deze gevallen de borden als correcter dan de BAG. Degene die de BAG-import heeft gedaan heeft de import-regels netjes opgevolgd en deze straatnamen verbeterd zodat ze nu wel overeenstemmen met de BAG, maar niet langer met de borden en de conventies. Dus hebben we een situatie geschapen waarbij een officieel register zwaarder wordt gewogen dan de werkelijkheid ter plaatse. Hiermee overschrijden we één van de basisbeginselen van OSM. Wat vindt men hier zoal van? Het on-the-ground principe voor de extacte schrijfwijze van borden weegt wat mij betreft niet zo zwaar. De borden horen ook de BAG aan te houden, maar stammen waarschijnlijk van voor de tijd dat dit een wettelijk plicht was. Of wijken hier van af ivm beperkte ruimte op de borden. Geen van de schijfwijzen is wat mij betreft fout, dus beide zijn prima acceptabel voor OSM. Het komt uit eindelijke neer een kwestie van smaak en estetische waarde. Mvg, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] luchtfotos 2014 via PDOK: licentie?
Vraag: is het de moeite waard/is er ervaring mee om deze luchtfoto specifiek voor OSM-overtekendoeleinden van een bredere licentie te voorzien? De licentie voorwaarden zijn te beperkend om bruikbaar te zijn voor OSM en de bredere open geo community, dus ja het is de moeite waard om een andere licentie te vragen. Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fwd: [Bug 531285] Use OpenStreetmap for maps (even allow the user to choose from list of map services)
Hoe ze het oplossen is natuurlijk hun zaak ;) Mozilla heeft genoeg resources om zelf een tileserver te hosten. ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Juridische eisen aan data voor import
On 03/11/2015 08:23 PM, Willy Bakker wrote: Stel je wilt data die beschikbaar is gesteld door een partij overnemen in OpenStreetMap. Wat zijn dan de juridische eisen aan de data? Als de data zich in het publieke domein bevinden (m.a.w. gepubliceerd zijn met een 'public domain mark') of beschikbaar zijn gesteld onder een Creative Commons Zero (CC0) licentie, lijkt het me geen probleem. Het opnemen van public-domain CC0 data in OSM is geen probleem, want de data is expliciet vijgesteld van copyright. Maar hoe zit dat met data waarvan niet duidelijk is wat de licentie voor hergebruik is? Ik neem aan dat het overnemen van de data in OpenStreetMap dan uitgesloten is. Als er geen duidelijke licentie voor de data is gelden automatisch de copyright regels waarbij alle rechten zijn voorbehouden aan de auteur. De auteur/copyright houder moet expliciet afstand nemen van deze exclusieve rechten door de werken onder een bepaalde licentie uit te brengen. En wat als de data een CC-BY, CC-NC of CC-SA licentie hebben? Dan voorzie ik toch ook problemen of heb ik het mis? De licentie van de werken die je in OSM wilt opnemen moeten herlicensering onder de ODbL toestaan zoals gebruikt voor de OSM database. Er is geen duidelijke compatibility matrix voor de ODbL en andere licenties zoals voor open source licenties wel het geval is. CC-BY is in principe wel mogelijk, maar je moet dan wel aan de attribution eis van de CC-BY licentie voldoen door de attribution toe te voegen aan de OSM copyright pagina. http://www.openstreetmap.org/copyright Voordat je die wijziging er door hebt ben je een flamewar verder. Dit is een belangrijke reden waarom CBS wijken buurten niet in OSM zijn opgenomen, ondanks dat het wel mogelijk is met attribution. De ODbL staat commercieel gebruik toe, dus CC-NC werken zijn daarmee niet compatible. CC-SA werken zijn ook problematisch, omdat de ODbL niet share-alike genoeg is waardoor de CC-SA licentie het herlicenseren onder de ODbL niet toe staat. Graag jullie mening. Ik ben geen jurist, dus bovenstaande heeft geen juridische waarde. Door mijn werkzaamheden voor Debian ben ik echter wel bekend met typische licentie periekelen als deze. Op de legal-talk lijst zal je meer OSM specifieke kennis vinden: https://lists.openstreetmap.org/pipermail/legal-talk/ Mvg, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] URL of Website
In oudere gegevens van scholen, winkels enz. zijn er bij een behoorlijk aantal de website toegevoegd in de vorm van URL:AH.nl Josm is nu aan het klagen en wil graag dat het nu gebeurt in de vorm van website:http://AH.nl Na enig zoeken vond ik deze webpagina: http://wiki.openstreetmap.org/wiki/Key:url Hoe gaan we hier mee om? De oplossing lijkt voor de hand te liggen: De URL aanpassen naar het valide format, dus inclusief schema (http:// of https://). Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] URL of Website
Gaan we dit handmatig doen? we? Volgens mij heb jij de wens om dit aan te passen, dus als het is aan jou om te kiezen tussen handmatig aanpassen of dit proces te automatiseren. Handmatige verwerking heeft de voorkeur omdat je dan geen mechanical edit hoeft goed te laten keuren. Ook heb je meer controle over edge cases die je snel over het hoofd ziet als je alles geautomatiseerd aanpast. Met mechanische edits is het eenvoudig veel data in een keer foutief te bewerken, wat het belangrijkste argument is om mechanische edits eerst met de community te bespreken. Ik zie regelmatig scripts voorbij komen die wereldwijd van alles en nog wat aanpassen. Ik kan me voorstellen dat dit een aardig klusje daarvoor is. Als je het meer dan een handvol objecten wilt aanpassen ligt automatiseren voor de hand, maar daarvoor moet je wel door het politieke process heen. M.i. is het een betere besteding van je tijd om de objecten die je tegenkomt bij het mappen aan te passen en de rest te laten voor wat het is. Als dit probleem door QA tools als Osmose getoont word is het voor andere mappers makkelijker om te helpen bij het corrigeren van de url tags als zij dat ook als een probleem ervaren. Voor data consumers is het een gegeven dat ze met verschillende formats overweg moeten kunnen. Veel daarvan zullen de ontbrekende schemas zelf toevoegen waardoor het niet veel uit maakt dat het in de OSM data ontbreekt. Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Gemeentelijke herindeling
On 12/27/2014 07:06 PM, Stefan de Konink wrote: On Saturday, December 27, 2014 4:24:16 PM CEST, Sebastiaan Couwenberg wrote: De belangrijkste reden om de gemeentelijk indeling nu nog niet te uploaden is de ingangsdatum van 1 januari. Het is erg voorbarig om het daarvoor al te uploaden. Geef even een seintje wanneer het er doorheen is. Dan gooi ik tile.openstreetmap.nl even helemaal leeg. Als het goed is is exporteer functie om bestanden te wissen weer gerepareerd, kunnen we op 1-1 weer mooi beginnen. Done: http://www.openstreetmap.org/changeset/27832460 Met de beste wensen voor 2015! Mvg, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Gemeentelijke herindeling
On 12/27/2014 02:54 PM, wouter van der plas wrote: het is al bijna 2015. op 1 jan gaan de Gemeentelijke herindeling van krach dus ik dacht ze nu maar alvast in osm te zetten. Doe nog maar even niet! maar ik weet niet of dat andere hier al mee bezig waren. ik zelf woon in Bernisse die samengevoegd word met Spijkenisse. maar ik vind het ook niet erg om de anderen ook te doen. mijn vraag is kan ik Bernisse en Spijkenisse samen voegen en wat gaan we doen met de andere gemeenten die worden samengevoegd Ik heb de gehele gemeentelijke indeling 2015 al weken klaar staat om op 1 januari 2015 om 00:00 te uploaden naar OSM. Het liefst hoef ik dan de conflicten met jou of andersmans edits niet op te lossen. Mvg, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Gemeentelijke herindeling
On 12/27/2014 03:20 PM, wouter van der plas wrote: ok dat is begrepen en ik zie het vanzelf verschijnen Hartelijk dank daarvoor. De belangrijkste reden om de gemeentelijk indeling nu nog niet te uploaden is de ingangsdatum van 1 januari. Het is erg voorbarig om het daarvoor al te uploaden. Mvg, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Gemeentelijke herindeling
On 12/27/2014 07:06 PM, Stefan de Konink wrote: Geef even een seintje wanneer het er doorheen is. Will do. Mvg, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Maandelijkse PostGIS en CSV dumps BAG beschikbaar op data.nlextract.nl/bag
Een autonoom (cron) proces checkt dagelijks of er op de PDOK site een nieuw BAG bronbestand beschikbaar is, gebruikmakend van de zgn PDOK BAG Atomfeed. Als de Atomfile (via datum veld) aangeeft dat de BAG vernieuwd is, wordt deze gedownload en met NLExtract-BAG ingelezen en verrijkt (provincies, gemeenten, adres tabel) in PostGIS. Vervolgens worden PostGIS en CSV dumps aangemaakt en ter download neergezet. Voor mijn eigen BAG database doe ik nagenoeg hetzelfde. Voor het automatisch kunnen importeren van de inspireadressen moest ik wel een argument toevoegen aan NLExtract om niet te prompten, hoe hebben jullie dat opgelost zodat er geen interactie nodig is? Normaal gesproken zal er op iedere 8e/9e van de maand een verse BAG zijn, hoewel PDOK recentelijk wat storingen daarin had... De updates van oktober en november zijn dit jaar net als vorig jaar overgeslagen. Dat vorige jaar dezelfde maanden zijn overgeslagen is opvallend, ik vermoed een structureel probleem. Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [Dutch] Maandelijkse PostGIS en CSV dumps BAG beschikbaar op data.nlextract.nl/bag
On 23-12-14 13:17, Sebastiaan Couwenberg wrote: Een autonoom (cron) proces checkt dagelijks of er op de PDOK site een nieuw BAG bronbestand beschikbaar is, gebruikmakend van de zgn PDOK BAG Atomfeed. Als de Atomfile (via datum veld) aangeeft dat de BAG vernieuwd is, wordt deze gedownload en met NLExtract-BAG ingelezen en verrijkt (provincies, gemeenten, adres tabel) in PostGIS. Vervolgens worden PostGIS en CSV dumps aangemaakt en ter download neergezet. Voor mijn eigen BAG database doe ik nagenoeg hetzelfde. Voor het automatisch kunnen importeren van de inspireadressen moest ik wel een argument toevoegen aan NLExtract om niet te prompten, hoe hebben jullie dat opgelost zodat er geen interactie nodig is? Ja daar moet een override-optie komen. Voorlopig zo opgelost: ./bag-extract.sh -c ja.txt en in ja.txt staat alleen 'j' ;-) Ik heb mijn change hiervoor geforward in een pull request: https://github.com/opengeogroep/NLExtract/pull/135 Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Privacy van deze mailinglijst?
On 12/24/2014 08:39 AM, Léon Tebbens wrote: Hoe kunnen we ervoor zorgen dat emailadressen onzichtbaar gemaakt worden? Door de mailinglist administrators aan te schrijven en niet de lijst. :) Talk-nl list run by henk at toffehoff.nl, mvexel at gmail.com ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Toevoegen aan adres-node?
On 12/11/2014 08:34 PM, Marc Zoutendijk wrote: Bij de BAG import zijn ook alle adrestags meegekomen, en mijn vraag is of ik aan zo'n adrestag wat mag toevoegen? Waarom denk je hier toestemming voor nodig te hebben? Nu ik bezig ben (zie links hieronder) met al die amenity en shop tags, zou het praktisch zijn om aan zo'n adrestag ook de overige eigenschappen van dat adres toe te voegen. Dus als ik het adres van de bakker weet, mag ik dan aan die adrestag ook shop=bakery vastmaken? Zolang er niet meerdere features zijn op het zelfde adres is het prima om de tags aan de adres node te hangen. Als er verschillende features op hetzelfde adres zitten is het beter de adres node te dupliceren voor elke afzonderlijke feature en deze binnen de pandcontour te verdelen. Mvg, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Wikipedia
On 11/16/2014 12:08 PM, Gertjan Idema wrote: Waar ik zelf nog niet helemaal uit ben, is hoe je de wikipedia pagina's van plaatsen in Friesland zou moeten taggen. Zelf heb ik voor de gemeentes wikipedia=nl:... gebruikt en ik zag dat Bas dat voor de woonplaatsen ook doet. Maar als je de regels strikt zou naleven, zou je misschien wikipedia:fy moeten gebruiken. In België gebruiken ze wikipedia:fr voor Luik, wikipedia:de voor Eupen en wikipedia:nl voor Antwerpen. Ik laat het aan de Friezen over om wikipedia:fy tags toe te voegen zoals ze ook doen met name:fy :) Mvg, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Wikipedia
On 11/16/2014 07:03 AM, Ronald Stroethoff wrote: Sebastiaan Couwenberg wrote: On 11/15/2014 05:09 PM, Ronald Stroethoff wrote: Ik zie dat iemand druk bezig is met het maken van links naar wikipedia. Heb je expliciete voorbeeld, links naar een of meer changesets helpt bij het beoordelen van de wijzigingen. http://www.openstreetmap.org/changeset/26768915 Dit is een changeset van mij, daarin heb ik alleen wikipedia tags toegevoegd. Deze changeset komt niet overeen met je klacht over wereldwijde edits waar meerdere wikipedia tags worden vervangen met een enkele. Mvg, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Wikipedia
On 11/16/2014 07:06 AM, Ronald Stroethoff wrote: Sebastiaan Couwenberg wrote: On 11/15/2014 05:09 PM, Ronald Stroethoff wrote: Ik zie dat iemand druk bezig is met het maken van links naar wikipedia. Heb je expliciete voorbeeld, links naar een of meer changesets helpt bij het beoordelen van de wijzigingen. http://www.openstreetmap.org/changeset/26714979 In deze changeset worden wel meerdere wikipedia tags verwijdert om alleen de primaire taal over te houden. Als ik even snel kijk naar de andere talen hebben die artikelen geen meerwaarde over het artikel in de primaire taal. Maar ik ben niet alle talen machtig om het inhoudelijk goed te kunnen beoordelen. In principe zie ik ook geen probleem met deze changeset. Mocht je van mening zijn dat de extra wikipedia tags toch wel meerwaarde bieden, ze dan gerust terug en ga in discussie met Jake Strine over het verwijderen van de tags. Mvg, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Wikipedia
On 11/15/2014 05:09 PM, Ronald Stroethoff wrote: Ik zie dat iemand druk bezig is met het maken van links naar wikipedia. Heb je expliciete voorbeeld, links naar een of meer changesets helpt bij het beoordelen van de wijzigingen. Ik heb zelf bijvoorbeeld recent wikipedia tags toegevoegd voor alle woonplaatsgrenzen. De gebruikte manier is: wikipedia=nl:Warmond Op de website: http://wiki.openstreetmap.org/wiki/Key:wikipedia worden twee manieren genoemd: wikipedia=en:St Paul's Cathedral en wikipedia:en=Museums in Paris vooral bij grotere plaatsen en toeristische plekken is de kans groot dat er wikipedia-pagina´s in meerdere talen zijn. In principe is een wikipedia tag genoeg, via de interwiki links kan met bij de andere talen komen. Voor het geval een object in een andere taal beter beschreven word kunnen de taal specifieke (wikipedia:lang=*) tags ook toegevoegd worden. Voor het toevoegen van extra wikipedia tags moet de extra taal meerwaarde bieden boven het artikel in de taal van het betreffende land. Ik heb al wereldwijde edits gezien waarbij een locatie een hele rits pagina ´s had, en die dus vervangen door 1 pagina. Als er geen meerwaarde zit in de andere talen is een wikipedia tag voldoende. Dus er is niet per se een probleem met deze edits als door jou beschreven. Graag hoor ik hoe we hiermee moeten omgaan? Tot dusver zie ik geen probleem, dus lekker zo laten. Mvg, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Sites met OSM zonder attribution
Maar o.a. om het OSM project meer bekendheid te geven, vragen we steeds dat er een copyright notice op de kaartjes staat. Wanneer OSM data gebruikt worden en niet alleen tiles (die onder CC-BY-SA licentie vallen), is de belangrijkste reden dat de ODbL licentie attribution vereist zoals in duidelijke taal beschreven in de summary: http://opendatacommons.org/licenses/odbl/summary/ De OSM legal FAQ is ook een goede resource om naar te verwijzen: http://wiki.openstreetmap.org/wiki/Legal_FAQ/CC-BY-SA_Archive#I_would_like_to_use_OpenStreetMap_maps._How_should_I_credit_you.3F In het schrijven zou ik deze links opnemen zodat men de achtergrond informatie eenvoudig kan raadplegen. Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM verjaardagsfeestje
Er is nog weinig gebruikt gemaakt van de Doodle ondanks het overnemen van het bericht op het forum. Wat de locatie betreft zijn er in de buurt van de Onze-Lieve-Vrouwetoren diverse kroegen te vinden. Dat lijkt me de aangewezen locatie als de keus op Amersfoort valt. Mvg, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG import nacontrole
On 07/25/2014 12:11 PM, Maarten Deen wrote: Kan iemand dit ook even op het forum wil posten? Done: http://forum.openstreetmap.org/viewtopic.php?id=26440 Mvg, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Mapping party Friesland
On 07/25/2014 08:57 PM, Harry van der Wolf wrote: Goed, en nu? Friesland is ondertussen gedaan door rivw en Mapping_Fryslan. Annuleren of ..? Volgens mij is het stuk dat Johan had gereserveerd nog niet gedaan door rivw noch Mapping_Fryslan, dus in dat opzicht hoeft er niets te veranderen aan het plan. Verder is de import nog klaar voor heel Nederland, er zijn nog ongeclaimde gemeentes op de intekenlijst en gaten zichtbaar in jouw polygons pagina. Die vullen met behulp van de aanwezige mappers lijkt mij een goede optie als ook de gereserveerde gemeentes intussen toch worden geimporteerd. Mvg, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Eems-Dollardgebied
Weet iemand hoe de uiteindelijke grens komt te liggen in het Eems-Dollardgebied? Dit is nog niet duidelijk. Maar gezien er slechts gesproken word over afspraken over wie waarvoor verantwoordelijk is, vermoed ik dat er geen grens aanpassing komt. De NL grens is al volgens de internationale afspraken, de nieuwe Duitse grens is dit echter niet. Duitsland moet het akkoord nog goedkeuren waarna het in een officieel verdrag omgezet kan worden. Voordat verdrag er is hoeven we iig nog niets te verwachten. Zie ook het draadje duitse grensverovering op het forum over dit issue: http://forum.openstreetmap.org/viewtopic.php?id=25074 Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] huisnummers in Amsterdam-West terug-draaien?
On 05/04/2014 07:30 PM, webmind wrote: On 27/04/14 13:52, Sebastiaan Couwenberg wrote: On 04/27/2014 01:34 PM, ekes wrote: On 27/04/14 12:09, Sebastiaan Couwenberg wrote: Het grote verschil is dat jou huisnummers de hele range in 1 node zetten, en de adressen vanuit de BAG allen afzonderlijke nodes zijn. De plaatsing van de huisnummers is vrijwel gelijk. De BAG plaatst ze in de verschillende verblijfsobjecten, en jij hebt ze bij de ingang geplaatst. Als ik kijk naar grote, meer complex, gebouwen, waar ik de panden van binnen ken. Er lijkt geen correlatie tussen de positie van kamers binnen de gebouw en de plaats waar de BAG import het node plaatst. Wat vinden mensen van zo een panden die zij kennen? Zodra er veel adressen binnen een pand vallen laat de plaatsing in de BAG wat te wensen over. De wolk adres nodes nodigt uit om deze te mergen tot een of een klein aantal nodes met meedere adressen. Dit breekt alleen met de BAG conventie die 1 adres per node gebruikt. Is dit een probleem? de semi willekeurige verdeling maakt er nu meer een zooitje van. De BAG plugin ondersteunt nog geen interpolated address ways, dat is een beperkende factor op dit moment. Nu we veel Nederlandse adressen in OSM hebben moeten we de richtlijnen hoe daarmee om te gaan uitwerken. Wat doen we bijvoorbeeld met adressen over meerdere verdiepingen? Wat ik me vooral practisch afvraag is, of ik nu de overbodige bag-nodes kan verwijderen of dat Nominatim dan huizen niet meer kan vinden. Kan als je tagged als 60-70 Nominatim daar huisnummer 62 in vinden? Nominatim ondersteunt interpolated address ways. Dus als je de addr:interpolation gebruikt kunnen de tussenliggende huisnummers ook gevonden worden. Zie bijvoorbeeld Amstelvlietstraat 351-571: http://www.openstreetmap.org/way/217536721 En bijvoorbeeld huisnummer 375: http://nominatim.openstreetmap.org/details.php?place_id=9177282248 Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] huisnummers in Amsterdam-West terug-draaien?
On 05/04/2014 08:21 PM, Sebastiaan Couwenberg wrote: On 05/04/2014 07:30 PM, webmind wrote: Wat ik me vooral practisch afvraag is, of ik nu de overbodige bag-nodes kan verwijderen of dat Nominatim dan huizen niet meer kan vinden. Kan als je tagged als 60-70 Nominatim daar huisnummer 62 in vinden? Nominatim ondersteunt interpolated address ways. Dus als je de addr:interpolation gebruikt kunnen de tussenliggende huisnummers ook gevonden worden. Zie bijvoorbeeld Amstelvlietstraat 351-571: http://www.openstreetmap.org/way/217536721 En bijvoorbeeld huisnummer 375: http://nominatim.openstreetmap.org/details.php?place_id=9177282248 Nominatim ondersteunt geen address interpolation op nodes, Ambulance Amsterdam op Karperweg 19-25 kan niet gevonden worden, met geen van de huisnummers noch de hele range. http://www.openstreetmap.org/node/2412984307 Of Rijtuigenhof 6-10, Amsterdam, de individuele adres nodes uit de BAG worden wel door Nominatim gevonden, maar de node met address interpolation niet. http://www.openstreetmap.org/node/565552584 Het samen voegen van adres nodes in een node m.b.v. interpolation is dus niet aan te raden. Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] huisnummers in Amsterdam-West terug-draaien?
On 04/26/2014 08:37 PM, clara wrote: Ik wilde het beste van allebeide: de goede huisnummers én de goed BAG informatie :) Zolang de HOT layer nog niet opnieuw gerendered is, heb je daar trouwens nog de correcte versie van huisnummers in het WG-Terrein.. Mischien iets om te verglijken. Op het moment van je eerste mail was de HOT rendering al gelijk aan de standaard OSM rendering. Ik gebruik die nooit, dus had een schone cache. Als ik de oude situatie vergelijk met behulp van de Geofabrik extract van 2014-02-01, zie ik eerlijk gezegd niet veel verschillen. Het grote verschil is dat jou huisnummers de hele range in 1 node zetten, en de adressen vanuit de BAG allen afzonderlijke nodes zijn. De plaatsing van de huisnummers is vrijwel gelijk. De BAG plaatst ze in de verschillende verblijfsobjecten, en jij hebt ze bij de ingang geplaatst. Ik heb jouw adres nodes uit de oude Geofrabrik extract gecopieeerd, en nu op de building way met entrance=yes gezet. Dit lijkt mij de best of both worlds. We hebben de adressen zoals ze in de BAG staan, en die hebben we in OSM nog eens verfijnt door de ingangen voor die adressen ook op te nemen. Is deze situatie voor jou ook goed nu? En mis je nog meer adressen bij ingangen die met de import verwijderd zijn? Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] huisnummers in Amsterdam-West terug-draaien?
On 04/27/2014 01:34 PM, ekes wrote: On 27/04/14 12:09, Sebastiaan Couwenberg wrote: Het grote verschil is dat jou huisnummers de hele range in 1 node zetten, en de adressen vanuit de BAG allen afzonderlijke nodes zijn. De plaatsing van de huisnummers is vrijwel gelijk. De BAG plaatst ze in de verschillende verblijfsobjecten, en jij hebt ze bij de ingang geplaatst. Als ik kijk naar grote, meer complex, gebouwen, waar ik de panden van binnen ken. Er lijkt geen correlatie tussen de positie van kamers binnen de gebouw en de plaats waar de BAG import het node plaatst. Wat vinden mensen van zo een panden die zij kennen? Zodra er veel adressen binnen een pand vallen laat de plaatsing in de BAG wat te wensen over. De wolk adres nodes nodigt uit om deze te mergen tot een of een klein aantal nodes met meedere adressen. Dit breekt alleen met de BAG conventie die 1 adres per node gebruikt. Ook er is geen indicatie van hoogte (level=)? Veel nodes binnen een complex pand liggen nu naast elkaar, terwijl ze beter boven op elkaar kunnen liggen als de bedoeling is om de binnenkant van de pand in kaart te brengen. De plugin verschuift de nodes die op exact dezelfde positie liggen een klein stukje om JOSM Validator waarschuwingen voor nodes-at-same-position te vermijden. Als de van de verblijfsobjecten hoogte informatie is af te leiden, zouden we de plugin aan kunnen passen om automatisch level=n tags toe te voegen. Ik zie dit anders, maar ook interessant, is met gesplitste huizen. Nummers 123-H, 123-1, 123-2 komen op elkaar, zonder level, en het lijkt toevallig welke gerenderd is. ekes Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] huisnummers in Amsterdam-West terug-draaien?
On 04/26/2014 05:08 PM, clara wrote: Verglijk bijvoorbeeld http://www.openstreetmap.org/?mlat=52.36320mlon=4.86989#map=18/52.36271/4.87015 en de nog niet nieuw gerenderde versie in de Humanitarian layer. http://www.openstreetmap.org/?mlat=52.36320mlon=4.86989#map=18/52.36300/4.86973layers=H Wat is de beste manier dat terug te draaien, zonder ook alle panden weer Waarom terug draaien als we de nieuwe situatie ook kunnen corrigeren? Gezien ik de BAG import in Amsterdam West heb gedaan, zal ik die taak op mij nemen. Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Donderdag mappersbabbel Amsterdam
Beetje late aankondiging maar morgen (donderdag de 20e) is er weer een Mappersbabbel in Amsterdam. [...] Vaste tijd en plaats: 19:00 bij Kaptein Zeppo's aan het 'Gebed Zonder End' in het centrum van Amsterdam. Ik ben in principe van de partij, maar ik ga 19:00 niet halen vrees ik. Gaat zaterdag 15 maart ook nog door op een andere locatie? Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fout in gemeentegrens bij Haarlem door BAG import
En waarom niet gemeente ipv gem.? Of zijn er daar edelstenen te vinden? Omdat de naam in de BAG 'Spaarndam gem. Haarlem' is. Deze naam moet in een name tag terug te vinden zijn. Voor display doeleinden heeft Spaarndam de voorkeur tenzij op de borden iets anders staat, voor matching met de BAG data is diens benaming nodig. official_name was in principe alleen voor land namen zoals beschreven in de wiki, dus is maar voor alt_name gekozen. http://wiki.openstreetmap.org/wiki/Key:name Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fout in gemeentegrens bij Haarlem door BAG import
On 01/14/2014 07:34 PM, Léon Tebbens wrote: De gemeentegrens tussen Haarlem en Spaardam geeft foutmeldingen in Keepright: http://keepright.ipax.at/report_map.php?schema=90error=45475266 . Ik kom er niet achter wat het probleem is. Lijkt te komen door de BAG import. Iemand een idee wat hier mis is? KeepRight kan niet goed overweg met boundaries, wanneer KeepRight klaagt over een boundary is het verstandig om OSMI te raadplegen of de multipolygon ook invalid is of dat er een invalid geometry gerapporteerd word. 999 van de 1000 keer zijn de boundary split warnings in KeepRight onterecht, en is de boundary correct. Op het punt in kwestie komen 3 woonplaatsen en 3 gemeenten samen, alle 6 deze relaties zijn gewoon valid. Haal ze maar eens door de JOSM validator en relation anaylizer. Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fout in gemeentegrens bij Haarlem door BAG import
On 01/14/2014 11:16 PM, Gertjan Idema wrote: Blijkbaar kan Keepright niet goed tegen twee administratieve gebieden met de zelfde naam op het zelfde level die aan elkaar grenzen. Volgens mij is het nog simpeler dan dat, in de KeepRight code waar deze warning vandaan komt staat het volgende: // degenerated loops are not rings. for example: // // +---+ // | | // | | // +---+- // // they can be found because the invalid junction node // belongs to three ways. The algorithm of ordering ways // assigns one sequence_id twice KeepRight staat vol met The boundary of $1 splits here warnings, voor elke node die deel is van meer dan 2 boundary relaties. Ik zie niet zo snel een fix voor dit probleem. En het helpt ook niet dat KeepRight niet meer actief onderhouden word, waardoor het erg onwaarschijnlijk is dat de originele developer het op kan lossen. We doen er waarschijnlijk goed aan dit issue te documenteren, zodat het feit dat dit false positives zijn makkelijker te vinden is. Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) ___ 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 *5-min per Spreker*
Hi Just, Ik heb geen spreektijd nodig, mijn vorige mail was slechts bedoeld om te bevestigen dat ik van plan ben om te komen. En om aan te geven dat geintreseerden mij aan de broek kunnen trekken voor een praatje over Debian GIS en OSGeo-Live of de BAG woonplaats grenzen tools als daar behoefte voor is. In het uitzonderlijke geval dat daar veel animo voor was zou ik bereid zijn mijn podiumvrees te trotseren en toch een praatje voor de hele zaal te houden, maar dat lijkt niet nodig gelukkig :-) Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) ___ 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
Hi Just, Ook ik ben van de partij in Hilversum. Ik ben echter niet erg comfortabel met public speaking, maar wil wel ter plekke iets vertellen/demoen over het Debian GIS project en wat het voor OSGeo Live kan betekenen en/of mijn BAG woonplaats grenzen tools, als daar interesse in is. Mvg, Bas On 12/19/2013 06:16 PM, Frank Steggink wrote: 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 -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Binnenkort ieder DAG een verse BAG!
Elke dag verse BAG data is erg fijn. On 01/03/2014 03:05 PM, Gert-Jan van der Weijden wrote: De downloadservice (http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen .xml), waarmee je de gehele dataset in een keer kunt downloaden en bijv. in NL-extract kunt verwerken blijft een maandelijkse updatefrequentie houden. Daadwerkelijk elke maand een nieuwe release in de ATOM service is nog veel fijner. Hopelijk zijn de FME issues nu opgelost waardoor dit weer mogelijk word. En maakt de aanstaande BAG update gebruik van de gemeentelijk indeling 2014, en is het niet nog de data van december 2013. Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] nationaalgeoregister WFS service query
On 10/17/2013 12:36 AM, nouwsfam wrote: Ik heb nog twee wensen: a) bepaalde gemeenten uitfilteren. Dat kan waarschijnlijk niet aan de kant van de WFS server. Dus ik zal een filter in openlayers moeten aanbrengen, nietwaar? b) de data gemeenten_2012 kan ik voor deze toepassing net zo goed lokaal opslaan (xml) en lokaal laden. Op welke manier moet ik deze data dan inlezen via OpenLayers? Ik zou beide wensen combineren door de TOPgrenzen zelf in een PostGIS database te laden en met MapServer of Geoserver via WFS/WMS te serveren. Zoals ik in het topic op het forum eerder had gepost. Het is wel wat meer werk, maar daardoor heb je wel alles in eigen hand om naar hartenlust aan te passen. In mijn OpenLayers site heb ik naast de PDOK BAG WFS ook mijn eigen BAG WFS (momenteel alleen woonplaatsgrenzen), omdat de PDOK BAG WFS niet genoeg metadata bevat voor wat ik ermee wil doen. Wederom is de OpenLayers route weer laagdrempeliger. Filteren van WFS requests is mogelijk. Dit voorbeeld heb je vast al gevonden: http://dev.openlayers.org/releases/OpenLayers-2.13.1/examples/wfs-filter.html Dit is voor wens a, voor wens b moet je toch echt met OGC servers aan de slag. Hoewel je misschien af kan met een caching proxy als zoiets bestaat voor WFS services. Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] nationaalgeoregister WFS service query
On 10/15/2013 11:49 PM, nouwsfam wrote: Is er iemand die mij een voorbeeld kan geven van hoe ik de gemeentegrenzen_2012 uit de WFS service van geodata.nationaalgeoregister.nl kan krijgen? In mijn OpenLayers site gebruik ik jQuery om m.b.v. de GetCapabilities requests dynamisch WFS layers toe te voegen. Voor de bestuurlijke grenzen WFS word uiteindelijk een Vector Layer als deze gegenereerd: wfs_layers[key][i] = new OpenLayers.Layer.Vector(layer_name, { strategies: [new OpenLayers.Strategy.BBOX()], protocol: new OpenLayers.Protocol.WFS({ version: 1.0.0, srsName: 'EPSG:28992', url: 'http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs', featurePrefix: 'bestuurlijkegrenzen', featureType: 'gemeenten_2012', featureNS: 'http://bestuurlijkegrenzen.geonovum.nl', geometryName: 'geom', }), projection: new OpenLayers.Projection('EPSG:28992'), styleMap: wfs_stylemap[key], }); map.addLayer(wfs_layers[key][i]); Het verschil met jou versie is het specificeren van andere geometryName, en de featureType en featurePrefix worden afzonderlijk gespecifieerd, evenals het gebruik van versie 1.0.0 van het WFS protocol. Het is mij niet helemaal duidelijk wat er mis is met jouw Vector Layer. Ik vermoed extra vereisten in versie 1.1.0 WFS requests. Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Tweede Coentunnel
Klopt het dat er momenteel geen verbinding van de tunnelbuis richting noorden naar de A8 is? Je wordt via de S118 en de Verlengde Stellingweg gestuurd. http://osrm.at/3ex Volgens mij klopt dat niet. Ik ben gister over de A5 van Schiphol naar het Coenplein gereden, en aan de andere kant van de tunnel kan je gewoon door over de A8. Op het moment word het verkeer door de nieuwe tunnelbuizen gestuurd, en zijn de oude voorlopig gesloten voor onderhoud. Dat moet nog gereflecteerd worden in OSM. En de terugweg wordt ook niet via de Coentunnel gestuurd, maar ik hoop dat dat is omdat way 115021650 de verkeerde kant op ging. De westelijke nieuwe tunnelbuis is als oneway:reversible aangeduid, ik hoop dat de routeplanners daarmee om kunnen gaan (en klopt dit met de werkelijkheid?). Ik heb helaas geen beeldmateriaal van de rit bij gebrek aan een dashcam, maar op Youtube staan wel wat fimpjes van iemand anders: https://www.youtube.com/watch?v=WxMYT4sLFMw https://www.youtube.com/watch?v=0cHhsVmyoVg https://www.youtube.com/watch?v=VVJaPLXf6Y0 Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Tweede Coentunnel
On 05/14/2013 10:08 PM, Johan C wrote: Heeft iemand al een foto genomen van de verkeersborden ter plaatse zodat de destination en destination:ref tags ingevoerd kunnen worden? Gezien we niet stil mogen staan op de snelweg zal foto's maken lastig worden. Op de rit videos op Youtube zijn de borden niet altijd evengoed leesbaar. Op de animatie videos van Rijkswaterstaat over de Westrandweg staan de borden duidelijk aangegeven. Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Tweede Coentunnel
On 05/14/2013 11:24 PM, Johan C wrote: Met de betere dashcam of als bijrijder met een compactcamera werkt ook goed. Het hoeven niet per se statieportretten te zijn :-) Heb je deze al gezien? https://www.youtube.com/watch?v=2G1ZcCpJ_Ec Elk bord word individueel gehighlight, veel duidelijker ga je het niet krijgen denk ik. De andere videos in deze playlist zijn ook de moeite waard: https://www.youtube.com/watch?v=xVlPJhNpv_olist=PL0A5728D0E79CF904 Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Tweede Coentunnel
Meer details zijn in het bestemmingsplan 'Westrandweg-2e Coentunnel' te vinden: http://www.ruimtelijkeplannen.nl/documents/NL.IMRO.0363.B0902BPGST-OH01/t_NL.IMRO.0363.B0902BPGST-OH01_4.1.html Of zijn dat niet de details waar je naar zocht? Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Multi poligons
Beste Ronald, Het is mij ook niet helemaal duidelijk wat het probleem met de multipolygons zijn. On 04/04/2013 09:23 PM, Ronald Stroethoff wrote: Op deze plek: http://www.openstreetmap.org/?lat=52.2113lon=4.57431zoom=17layers=M Er is hier een MP voor de Kager Plassen met een outer member voor het water en meerdere inner members voor de eilanden daarin. Maar deze zijn niet compleet, het eiland net over de grens in de Kaag is geen member van de MP. Wilde ik enige verbeteringen aanbrengen, namelijk een stukje water bleek een passantenhaventje te zijn en een ander stuk water heeft een eigen naam. Hiervoor moest ik dus het water in stukken knippen. De haven had je ook zonder knippen als nieuwe way kunnen taggen die gebruik maakt van de bestaande nodes die het stuk water en grass met elkaar verbinden. Ik kwam daar meerdere problemen tegen 1) stukken weiland lagen met de punten op de punten van het water waardoor ze niet apart te selecteren zijn. Middelklik in JOSM om de diverse objecten op dat punt individueel te kunnen selecteren (met Ctrl+Klik). 2) bij het knippen begonnen verschillende relaties te protesteren. Als je de way selecteerd kan je in JOSM de relaties waar deze onderdeel van zien in de Properties, rechtklik en download de incomplete members van alle relaties voordat je hem opknipt. Dan past JOSM de relaties automatisch voor je aan. ronald Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Bussen van De Lijn in Maastricht/Tilburg
On 03/13/2013 06:56 PM, Jo wrote: Is deze mailing list dood en had ik m'n ei elders moeten leggen? Deze ML is niet dood, maar wel dun bevolkt. Op het forum is meer activiteit van mappers, hier zitten de techneuten heb ik het idee. Om te beginnen zou ik dit issue op het forum aankaarten, de kans dat seat ibiza daar meeleest is groter. Maar het is geen garantie, het geeft wel een breder publiek inzicht in jou motivatie en werkzaamheden. Een bericht aan seat ibiza sturen kan je daarna doen en verwijzen naar de draadjes op de ML en het forum. Niemand staat in een positie om anderen te vertellen wat ze moeten doen, maar met wat peer pressure kan je het waarschijnlijk wel de juiste richting op sturen. Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)
On 03/03/2013 09:52 PM, Minko wrote: Ok, ik heb de situatie daar weer hersteld. Die zaten kennelijk aan de grenzen vastgeklikt? Dat klopt. Ik ben er nog niet aan toegekomen om alle grenzen die ik heb aangepast te controleren op dit soort zaken. Even nadat de database weer read/write was gemaakt heb ik mijn laatste changeset geupload met niet-boundary verbonden aan boundary fixes. Hiermee zou alle vreemde knikken veroorzaakt met het verplaatsen van boundaries weer in order gemaakt moeten zijn. Later dit weekend moet ik mijn rappotage script nog eens draaien over een verse OSM extract voor Nederland ter controle van alles wat ik eventueel gemist heb en de nieuw geïntroduceerde verbindingen. Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)
On 03/03/2013 06:04 PM, Gertjan Idema wrote: Eén puntje wil ik wel in overweging geven: Als iemand netjes de officiële naam opgeeft in bijvoorbeeld nominatum, dan zou het wel zo prettig zijn als de bijbehorende plaats dan ook wordt gevonden. Op het moment word zelfs zonder het gebruik van de official_name tag voor beide namen vrijwel dezelfde resultaten getoont. Dus daar hoeven we het niet voor te doen. On 03/03/2013 06:04 PM, Gertjan Idema wrote: On Thu, 2013-02-28 at 01:46 +0100, Sebastiaan Couwenberg wrote: Huidige status: done: 2000, TODO: 484, Total: 2484 (complete: 80.5152979066023%) Als ik het goed heb, zouden het er 2500 moeten zijn. (2505 woonplaatscodes als je de 'dubbelen' mee telt). Klopt. Ik was Flevoland vergeten in het overzicht. Zuid Holland heb ik vandaag afgemaakt, en daarmee is de huidige status: done: 2152, TODO: 349, Total: 2501 (complete: 86.0455817672931%) On 03/03/2013 06:04 PM, Gertjan Idema wrote: On Thu, 2013-02-28 at 01:46 +0100, Sebastiaan Couwenberg wrote: Maar hiermee heb je niet de waterway=river wegen die vaak over grenzen getrokken zijn, en de verschillende highways, buildings e.d. Als je alle mogelijkheden wilt afvangen moet je alle data binnen de boundingbox ophalen en dat is al snel teveel voor een grote stad laat staan een hele gemeente of provincie. Als de rivier de officiële grens is, betwijfel ik of je grens en de rivier moet loskoppelen. Valt wat voor te zeggen. Maar het maakt het editten van boundaries buiten de volledige dataset om wel nodeloos meer werk. Idealiter leven de boundaries in hun eigen layer, omdat ze niet interacteren met de andere data. Ze hoeven niet gekoppeld te zijn voor routing of iets dergelijks. Hekken en degelijke barriers kunnen overlap hebben met boundaries en zouden van dezelfde ways en/of nodes gebruik kunnen maken als een hekwerk is geplaatst om de grens op locatie aan te duiden. Maar kunnen net zo goed los van elkaar staan. In mijn ogen is een administratieve grens een virtuele feature die per definitie losstaat van de features die op de grond kunnen bestaan. Zodoende dient de logische scheiding tussen de features behouden te worden door diens nodes en ways niet te combineren. Wanneer een rivier of andere niet-virtuele feature gebruikt word ter bepaling van een grens dient de logisch scheiding gerespecteerd te worden. Zo kunnen de ways over elkaar getekend worden maar geen nodes te sharen, of mijn voorkeur, teken de waterway en boundary vlak naast elkaar. On 03/03/2013 06:04 PM, Gertjan Idema wrote: On Thu, 2013-02-28 at 01:46 +0100, Sebastiaan Couwenberg wrote: On 02/27/2013 09:34 PM, Gertjan Idema wrote: On Sun, 2013-02-24 at 17:09 +0100, Sebastiaan Couwenberg wrote: Andere klussen: Het gebruik van type=boundary/type=multipolygon nog niet consequent. Volgens de Nederlandse conventie gebruiken we type=multipolygon. Op de internationale site staat echter dat type=multipolygon verouderd is. Dat is nogal verwarrend. Huidige status: multipolygon=2173x, boundary=327x Een van de JOSM ontwikkelaars pushed de standaardisatie naar type=boundary. En als je op basis van de wiki of taginfo beslist hoe te taggen zal type=boundary altijd de voorkeur hebben. Ik kan op zich leven met 'type=boundary' als dit overal behalve in Nederland en Duitsland de standaard is. Dan is het wel zaak om de Nederlandse documentatie hier op aan te passen. Eerst maar eens uitzoeken wat destijds de argumenten voor type=multipolygon waren. Het enige nadeel aan type=boundary is wat mij betreft dat hier standaard een warning voor getoond word in OSMI. Maar omdat deze super eenvoudig uitschakelen is, het dat redelijk een non-argument. Als type=boundary de officiële standaard is, is dat in mijn ogen een bug in OSMI die binnenkort wel verleden tijd zal zijn. Dat zou mooi zijn, maar ik weet het nog niet zo zeker. Het belangrijkste is dat wij documenteren welk type we gebruiken en waarom, en hoe dat afwijkt van bepaalde documentatie, QA tools, e.d. Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)
On 03/03/2013 07:47 PM, Minko wrote: Bas, Bij het editten van de grenzen heb je hier een aantal (fiets)paden mede verplaatst: http://www.openstreetmap.org/?lat=52.06349lon=6.07858zoom=17layers=M Die zaten kennelijk aan de grenzen vastgeklikt? Dat klopt. Ik ben er nog niet aan toegekomen om alle grenzen die ik heb aangepast te controleren op dit soort zaken. Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Nederland op de Best of OSM poster
Via de Weekly OSM Summary [1] kwam het nieuws tot mij dat de nieuwe Best Of OSM was gereleased. [2] Op de nieuwe poster [3] heeft Nederland ook een plekje gekregen dankzij het prachtige werk van JanFi om Paleis Het Loo, en voornamelijk de tuinen op de kaart te zetten. [4] Ook dank aan Lambertus voor de nominatie. [5] Dikke pluim voor JanFi! Nu aan ons de uitdaging om voor de volgende poster heel Nederland erop te krijgen als eerste land met volledige adres dekking dankzij de BAG! [1] http://opengeodata.org/weekly-osm-summary-63 [2] http://bestofosm.org/ [3] http://bestofosm.org/poster/ [4] http://bestofosm.org/#interesting-het-loo-garden [5] http://lists.openstreetmap.org/pipermail/talk/2012-December/065393.html Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)
On 02/27/2013 09:34 PM, Gertjan Idema wrote: On Sun, 2013-02-24 at 17:09 +0100, Sebastiaan Couwenberg wrote: Het is niet handig dat de ref:woonplaatscode van Putten is aangepast naar de code in de meest recente BAG zonder ook de geometrie aan te passen. De ref:woonplaatscode/name tuple hoorde bij de geometrie van het record in bag:extract WPL08082012, bij de aangepaste woonplaatscode zit ook een nieuwe geometrie van de woonplaats in bag:extract WPL08012013. Voor Putten er Nijkerk heb ik net ook de geometrie aangepast met de versie uit bag:extract WPL08012013. Ik was me er niet van bewust dat je al zo ver was met de BAG woonplaatsgrenzen. Dat is ook deels mijn schuld, ik heb er geen openbare progress report oid van bijgehouden zoals voor het Woonplaatsbesluiten project is gedaan. http://wiki.openstreetmap.org/wiki/Bestaande_geodata_hergebruiken_woonplaatsbesluiten Het is mijn bedoeling om een dergelijk overzicht te genereren met bijbehorende interactieve kaart voor de grenzen die in OSM geupdate kunnen worden met de meeste recente versie in de BAG. Hier wil ik pas echt goed voor gaan zitten als ik klaar ben met alle woonplaatsgrenzen gelijk trekken met de inmiddels wat oude BAG, maar gezien de woonplaatsen niet zoveel aan verandering onderhevig zijn als de panden vind ik dat niet zo'n probleem. Voordat de grenzen met BAG data geupdate werden was er tijden weinig tot niets aangepast, we zijn er dus op vooruit gegaan qua actualiteit, maar nog niet helemaal volledig up-to-date. In eerste instantie had ik mij ook voorgenomen om de procedure die ik volg bij het toevoegen en updaten van grenzen aan de BAGimport wiki pagina toe te voegen, maar ik twijfelde over het nut ervan. Het toevoegen van grenzen is een redelijk eenmalig proces, daarna zullen de bestaande grenzen aangepast worden. Tenzij er nog nieuwe woonplaatsen in het leven geroepen worden zal al het werk het updaten van bestaande grenzen omvatten. Het is leek mij nuttiger om dat proces te gaan documenteren wanneer alle ontbrekende grenzen waren toegevoegd. Daar is het nu dus wel tijd voor aan het worden, maar ik zal hoogst waarschijnlijk nog even procastinaten. Want ik wil mijn tijd nu nog even in de laatste 484 woonplaatsen steken. 2. 'Onlogische' woonplaatsnamen in de BAG: Bij een aantal plaatsen heb ik er voor gekozen om de naam in OSM niet aan te passen aan de officiële BAG namen. In plaats daarvan heb ik de BAG namen in de 'alt_name' tag geplaatst. Aan het lijstje hieronder is denk ik wel te zien waarom. (de tweede naam is de BAG naam): AlteveerAlteveer gem Hoogeveen BotlekBotlek Rotterdam De Hoefde Hoef De Luttede Lutte Den Haag's-Gravenhage De Woudede Woude ElstElst Ut EuropoortEuropoort Rotterdam HoogvlietHoogvliet Rotterdam MaasvlakteMaasvlakte Rotterdam PernisPernis Rotterdam 's-HertogenboschDen Bosch UrsemUrsem gem. S VondelingenplaatVondelingenplaat Rotterdam Ik twijfelde welke tag hiervoor te gebruiken, official_name was misschien ook een optie gezien de Woonplaats als zodanig in de officiele bron staat. Maar alt_name is waarschijnlijk beter. Bij http://wiki.openstreetmap.org/wiki/Key:official_name staat 'It has been created for country names'. Er staat dus niet bij dat het niet voor andere namen gebruikt mag worden. Ik neig er nu toch meer naar om 'official_name' te gaan gebruiken. Zodra we het er over eens zijn, kunnen we dit vermelden in de Nederlandse wiki. Tsja, interpretatie van tags blijft een lastig issue. Wat is de officiële naam van een woonplaats? Dat lijkt mij de naam die op officiële documenten gebruikt word, ik denk niet dat gemeente of provincie hints in de woonplaats naam onderdeel zijn van de officiële naam zoals op briefpapier van het stadsbestuur word gebruikt, op de plaatsnaamborden staat, en wat men in het postadres zou gebruiken. Het lijkt mij deze deze in het verleden zijn toegevoegd zodat om unique contraints in een database gewerkt kon worden, of om simpelweg in de oude kaartenbakken op basis van de naam het onderscheid te kunnen zien. Het hergebruiken van bestaande tags maar deze anders interpreteren voor een nieuw project zorgt voor nodeloze verwarring bij diegenen die bekent zijn met de originele insteek. Om dit te voorkomen kunnen we misschien beter onze eigen tag introduceren zodat we vrij zijn deze te definiëren. Zodoende voel ik er ook wel wat voor om bag:name of bag:woonplaatsnaam te gebruiken voor de naam zoals het in de BAG staat. Deze namespace is vrij voor ons om invulling te geven, en zullen minder snel aangepast worden als de name tag. Ik zie ook liever Alteveer op de kaart dan Alteveer gem Hoogeveen, de toevoeging tbv de uniekheid heeft geen meerwaarde ter rendering op de kaart. Ik wil hier niet al te veel tijd aan spenderen. Het belangrijkste is dat we een tag kiezen en deze consistent gebruiken zodat de tools er gebruik van kunnen maken. alt_name is lekker breed gedefinieerd en
Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)
On 02/24/2013 02:56 PM, Gertjan Idema wrote: Dankzij veel werk van vooral 'Sebastic' en 'It's so Funny', staan alle officiële woonplaatsen nu in de OSM database. Dit zijn de boundaries met admin_level=10. Naar aanleiding van een bericht van It's so funny had ik ook een mail over deze aangelegenheid in de pijpleiding zitten, maar daarvoor wij ik mijn grenzen rapportage compleet hebben. Je bent me weer eens te snel af. :) Zelf heb ik de ontbrekende woonplaatscodes toegevoegd en de woonplaatsnamen vergeleken met de BAG data van 8-1-2013. In twee situaties kan er een afwijking zijn t.o.v. de BAG: 1. Dubbele woonplaatscodes in de BAG: In overgangssituaties kan het voorkomen dat woonplaatsen in de BAG tijdelijk met oude en nieuwe woonplaatscodes voorkomen. Tijdelijk is hier een ruim begrip, want het kan meer dan een jaar zijn. In deze gevallen heb ik de nieuwste woonplaatscode in OSM gezet. Het gaat hier om: Apeldoorn, Leimuiden, Oudkarspel, Putten en Rijpwetering. Ik werk in principe nog op basis van de BAG van 08082012, maar ik heb ook de meeste recente van 08012013 in een aparte PostGIS DB staan. Van beide heb ik OSM files met de woonplaatsgrenzen met behulp van jouw bag4osm osmosis plugin (nog wel Putten had ik al gelijkgetrokken met de BAG van augustus vorig jaar, vandaar de oude woonplaatscode 2007. Bij de borrel afgelopen donderdag werd ik door Steven gewezen op de aangepaste grenzen per 1 januari 2013, Putten Nijkerk. Deze heb ik niet direct aangepast omdat ik ze als testcase voor mijn script wilde gebruiken. Het is niet handig dat de ref:woonplaatscode van Putten is aangepast naar de code in de meest recente BAG zonder ook de geometrie aan te passen. De ref:woonplaatscode/name tuple hoorde bij de geometrie van het record in bag:extract WPL08082012, bij de aangepaste woonplaatscode zit ook een nieuwe geometrie van de woonplaats in bag:extract WPL08012013. Voor Putten er Nijkerk heb ik net ook de geometrie aangepast met de versie uit bag:extract WPL08012013. 2. 'Onlogische' woonplaatsnamen in de BAG: Bij een aantal plaatsen heb ik er voor gekozen om de naam in OSM niet aan te passen aan de officiële BAG namen. In plaats daarvan heb ik de BAG namen in de 'alt_name' tag geplaatst. Aan het lijstje hieronder is denk ik wel te zien waarom. (de tweede naam is de BAG naam): AlteveerAlteveer gem Hoogeveen BotlekBotlek Rotterdam De Hoefde Hoef De Luttede Lutte Den Haag's-Gravenhage De Woudede Woude ElstElst Ut EuropoortEuropoort Rotterdam HoogvlietHoogvliet Rotterdam MaasvlakteMaasvlakte Rotterdam PernisPernis Rotterdam 's-HertogenboschDen Bosch UrsemUrsem gem. S VondelingenplaatVondelingenplaat Rotterdam Ik twijfelde welke tag hiervoor te gebruiken, official_name was misschien ook een optie gezien de Woonplaats als zodanig in de officiele bron staat. Maar alt_name is waarschijnlijk beter. Zien de OSM relations voor woonplaatsgrenzen met behulp van de ref:woonplaatscode en diens naam (name of alt_name) tag gekoppeld worden aan de records in de BAG is het van belang dat een van de twee tags (name of alt_name) overeen komen met de woonplaatsnaam in de BAG. Alteveer is trouwens een leuke, daarvan bestaan woonplaatsgrenzen in meerdere gemeentes, en in meerdere provincies. Gelukkig hebben we nu de ref:woonplaatscode om de 4 verschillende Alteveers te kunnen onderscheiden. Zoals ik in het onderwerp al vermeldde, betekent dit nog niet dat alle woonplaatsgrenzen nu netjes op de zelfde plek liggen als in de BAG. Dat is nog wel even werk. Alleen de provincies Zuid-Holland, Utrecht, Flevoland en Noord-Holland moeten nog gelijkgetrokken worden met de BAG, de overige provincies heb ik reeds voltooid. Wel moet ik alles nog eens met de meest recente BAG vergeleken worden wanneer alle admin_level=10 grenzen in OSM op basis van de BAG zijn. Deze vergelijking zal geautomatiseerd worden, het gelijk trekken van de overige provincies is nog wat handwerk in JOSM. Maar met de Replace Geometry functie is het minder tijdrovend dan het volledig handmatig mergen van alle nodes wat ik voorheen deed. Het nadeel is wel dat met het verschuiven van de nodes deze niet losgekoppeld worden van eventueel daaraan verbonden niet-boundary wegen. Hier heb ik nu ook een controle script voor die met behulp van een lokale OSM DB een rapportage maakt van alle niet-boundary wegen die verbonden zijn met een boundary. Het handmatig losknopen hiervan is ook nog best wat handwerk. De Replace Geometry functie in JOSM koppelt verbonden wegen automatisch los, maar dat kan alleen als de OSM data ervan beschikbaar is. Op zich niet zo'n probleem, want met wat Overpass Queries is deze data ook zo op te halen, alleen kost het uitvoeren hiervan meer tijd dan ik op het downloaden van alle grenzen binnen een provincie wil wachten. Nu doe ik een controle achter af. Na het updaten van alle grenzen binnen een gemeente check of er nog niet-boundary ways
Re: [OSM-talk-nl] Bot-wars
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
Re: [OSM-talk-nl] Het taggen van BAG data.
On 10/21/2012 11:52 AM, Frank Steggink wrote: Als een bouwvergunning verleend is, hoeft nog niet te betekenen dat al met de bouw gestart is. Ik wist trouwens niet dat deze status ook in de BAG aanwezig kan zijn. Geldt dit ook voor sloopvergunningen? Sloopvergunning verleent is ook een status die ik in de BAG ben tegen gekomen. Bijvoorbeeld ref:bagid=18951227 Burgemeester Schonfeldplein 2B, Winschoten De volgende statussen kom ik in de BAG tegen: count |pandstatus --+-- 135090 | Pand gesloopt 109979 | Bouw gestart 330795 | Pand in gebruik (niet ingemeten) 52579 | Sloopvergunning verleend 11109687 | Pand in gebruik 239848 | Bouwvergunning verleend 1656 | Pand buiten gebruik 41025 | Niet gerealiseerd pand (8 rows) Mvg, Bas -- GnuPG: 0x77A975AD ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] changeset terugdraaien
Met de BAG zijn we een van de weinige landen waar de adressen open data is. Voorzover ik kan zien is de BAG PD, zie: http://www.kadaster.nl/bag/over/nieuws-bericht.asp?Id=1326Id_Categorie=23 . Ook volgens de open data portal is het PD: https://data.overheid.nl/data/dataset/basisregistratie-adressen-en-gebouwen-bag- Ik denk dat als we de BAG of delen daarvan, willen (her)importeren, er bepaalde conventies moeten worden aangehouden. Er is natuurlijk al veel discussie geweest, en heb zelf niet alles kunnen volgen: http://wiki.openstreetmap.org/wiki/BAG . Ik zou die conventies daar opnemen. Een goed begin is de conventie in de changeset: http://www.openstreetmap.org/browse/way/185580580. E.e.a. dan uitproberen op een proefgebied als er automatisch geimporteerd wordt. De BAG is een 2-koppig monster: zowel adressen als gebouwen in een N-M relatie. Hoe hier in OSM mee om te gaan, bijv. adressen apart als virtuele nodes en via relations aan house-ways koppelen, of redundant? Goed, ik wil alleen zeggen: probeer een strategie te bedenken, voor herhaalbare imports, die ook rekening houdt met bestaande, hand-made adressen, eventuele exports tbv geocoding en probeer die eerst uit. Op het forum loopt ook een draadje waarin we de workflow voor BAG data proberen uit te werken: http://forum.openstreetmap.org/viewtopic.php?id=18311 Voorals nog zijn we niet op het punt om een importer te ontwikkelen, en de vraag is of dat wenselijk is. Op met moment werken we met de BAG data in een aparte laag in JOSM om deze handmatig te mergen in de actieve editting laag. Persoonlijk denk ik dat dit ook de workflow moet worden ipv dat we het werk uit de handen van mappers nemen en aan een geautomatiseerd proces over laten, moeten we tools ontwikkelen die het voor mappers makkelijk maakt om de BAG data in OSM te integreren. Zo wil ik met MapServer een WFS layer maken voor de BAG data, zodat je de data voor het stuk wat je aan het editten bent kunt ophalen direct in JOSM zoals je ook de OSM en GPS data kunt ophalen. Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fwd: [OSM-talk] Licence redaction ready to begin
Naar aanleiding van deze e-mail vraag ik mij af waarom het proces nu pas in gang gezet wordt, terwijl er nu maanden over de deadline is heen gegaan. Dat vroeg ik mij ook af, en vond het volgende in het archief van de Rebuild lijst: The work with the license change bot have almost halted the last month, with only around 10 commits and no real progress on the main algorithms. This is partly because people have been occupied with other stuff (work, life, mapping, final exams, etc) and partly because the problems with the algorithms are really hard. http://lists.openstreetmap.org/pipermail/rebuild/2012-June/000244.html I am finally done with my final exams for this semester and have turned my attention to the redaction bot. You have asked for updates and now I finally have some. http://lists.openstreetmap.org/pipermail/rebuild/2012-June/000252.html Het is natuurlijk goed dat een recente CC-BY-SA set (eindelijk) is gepubliceerd. Misschien een erg belangrijke vraag: is het proces van de bot door gebruikers te volgen? Wat is de gebruikersnaam van de bot? En hoe opereert de bot, maakt deze gebruik van de API? Wat ik uit de Rebuild lijst opmaak is er nog geen definitieve gebruikersnaam voor de bot gekozen, op dev gebruikt het momenteel de username 'nobody'. Zie hiervoor de berichten van de Andy Allen in de draad die begint bij: http://lists.openstreetmap.org/pipermail/rebuild/2012-July/000295.html In die draad is een link gepost naar de GitHub repo waar de bot code leeft: https://github.com/gravitystorm/openstreetmap-license-change/ Het maakt gebruik van de redaction features in de API die voorheen nog niet gebruikt werden. Dit is wat ik tot dusver over de status van de license change heb kunnen vinden. Ik vermoed dat in IRC logs nog wat details te vinden zijn die de maillinglist nog niet bereikt hebben. Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl