Hey Joost, On 01-06-16 16:19, joost schouppe wrote: > Well, it depends on your definition of vastly :)
very true... 100 meters would be vast imho. A difference of 5 meters I would think that is pretty much ok, although the importance of that can be big when borders cross buildings. > (I haven't looked at the size of the differences yet) > > I was talking about municipal borders (admin_level=8), postal codes as > in your example are a wholly different beast, one I wouldn't want to > tackle right now. I know it's not level 8, but it doesn't matter what a boundary represents, I had the Overpass query saved (it's ok to just call me lazy, not stupid ;-) ! ) All fun aside, in essence: it's really the same, a relation of ways that have stuff attached. admin levels are just a label representing concepts. > But yes, they have a lot of things sticking to them too. More important: remember that those boundaries usually align on each other, so when you make a admin level 8 smaller, you -probably- also need to modify all others as well. e.g. If you make north border of Antwerp smaller, you probably need to make Belgium smaller too, AND the province etc. probably even from level 1 down to 9 if you want to do this well. At the least we will need to verify them to make sure. GRB data actually has border information if I remember correctly. some of their map layers (tiles) show the level 8 boundary (a very fine line though, almost invisible). Glenn > > So when is our next hackathon to work on things like this? > > > 2016-06-01 16:00 GMT+02:00 Glenn Plas <gl...@byte-consult.be > <mailto:gl...@byte-consult.be>>: > > Hi, > > I'm not sure they can be vastly improved, it probably depends a lot on > what boundary. > > In that understanding that there is lot's of stuff attached to those > boundaries that shouldn't be there. So when you are working to improve > boundaries, you'll need to address plenty of those cases, and that will > slow you down (a lot) and prevent more automated fixes. > > One could also just go in and unglue all stuff that needs to be as a > preparation and work with clean -closed way- borders, no crap attached. > That would open the road for 'program-assisted' changes. > > Little example: http://overpass-turbo.eu/s/gz0 > > node 1712080972 : amenity attached to the border > > Greets, > > Glenn > > On 01-06-16 15:46, joost schouppe wrote: > > RIP Marc. > > > > So I understand the geometry of the municipal boundaries could be vastly > > improved. > > > > I'm guessing the easiest workflow would be to load just the geometry of > > the municipalities and just the OSM municipalities in JOSM, then merge > > the nodes of the OSM municipalities to the external data. Afterwards, > > just discard the external geometry. Right? > > > > I think I could quite easily identify the largest differences with FME > > to help set priorities. But I would think this is something where we > > would just want to copy the official dataset node for node, no? > > > > _______________________________________________ > Talk-be mailing list > Talk-be@openstreetmap.org <mailto:Talk-be@openstreetmap.org> > https://lists.openstreetmap.org/listinfo/talk-be > > > > > -- > Joost @ > Openstreetmap > <http://www.openstreetmap.org/user/joost%20schouppe/> | Twitter > <https://twitter.com/joostjakob> | LinkedIn > <https://www.linkedin.com/pub/joost-schouppe/48/939/603> | Meetup > <http://www.meetup.com/OpenStreetMap-Belgium/members/97979802/> > > > _______________________________________________ > Talk-be mailing list > Talk-be@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-be > _______________________________________________ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
