<div dir="ltr">Well, it depends on your definition of vastly :)<div>(I haven't looked at the size of the differences yet)</div><div><br></div><div>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.</div><div>But yes, they have a lot of things sticking to them too.</div><div><br></div><div>So when is our next hackathon to work on things like this?</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-01 16:00 GMT+02:00 Glenn Plas <span dir="ltr"><<a href="mailto:glenn@byte-consult.be" target="_blank">glenn@byte-consult.be</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I'm not sure they can be vastly improved, it probably depends a lot on<br>
what boundary.<br>
<br>
In that understanding that there is lot's of stuff attached to those<br>
boundaries that shouldn't be there.  So when you are working to improve<br>
boundaries, you'll need to address plenty of those cases, and that will<br>
slow you down (a lot) and prevent more automated fixes.<br>
<br>
One could also just go in and unglue all stuff that needs to be as a<br>
preparation and work with clean -closed way- borders, no crap attached.<br>
 That would open the road for 'program-assisted' changes.<br>
<br>
Little example: <a href="http://overpass-turbo.eu/s/gz0" rel="noreferrer" target="_blank">http://overpass-turbo.eu/s/gz0</a><br>
<br>
node 1712080972 : amenity attached to the border<br>
<br>
Greets,<br>
<br>
Glenn<br>
<span class="im HOEnZb"><br>
On 01-06-16 15:46, joost schouppe wrote:<br>
> RIP Marc.<br>
><br>
> So I understand the geometry of the municipal boundaries could be vastly<br>
> improved.<br>
><br>
> I'm guessing the easiest workflow would be to load just the geometry of<br>
> the municipalities and just the OSM municipalities in JOSM, then merge<br>
> the nodes of the OSM municipalities to the external data. Afterwards,<br>
> just discard the external geometry. Right?<br>
><br>
> I think I could quite easily identify the largest differences with FME<br>
> to help set priorities. But I would think this is something where we<br>
> would just want to copy the official dataset node for node, no?<br>
><br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Talk-be mailing list<br>
<a href="mailto:Talk-be@openstreetmap.org">Talk-be@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-be" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-be</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Joost @</div><div dir="ltr"><a href="http://www.openstreetmap.org/user/joost%20schouppe/" target="_blank">Openstreetmap</a> | <a href="https://twitter.com/joostjakob" target="_blank">Twitter</a> | <a href="https://www.linkedin.com/pub/joost-schouppe/48/939/603" target="_blank">LinkedIn</a> | <a href="http://www.meetup.com/OpenStreetMap-Belgium/members/97979802/" target="_blank">Meetup</a></div></div></div></div></div></div>
</div>