<div dir="ltr"><div class="gmail_extra">Hey Florian</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">2014-10-05 21:45 GMT+02:00 Florian Lohoff <span dir="ltr"><<a href="mailto:f@zz.de" target="_blank">f@zz.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Hi Johan,<br>
<span class=""><br>
On Sun, Oct 05, 2014 at 04:49:15PM +0200, Johan C wrote:<br>
> Hi Florian<br>
><br>
> I invite you to make comments on the OpenStreetMap forum (<br>
> <a href="http://forum.openstreetmap.org/viewforum.php?id=12" target="_blank">http://forum.openstreetmap.org/viewforum.php?id=12</a>) because there's more<br>
> Dutch mappers active there. Awaiting your input there, I'll already do a<br>
> short reply to you,<br>
<br>
</span>Hmm i am not the kind of Forum user. I like my email program which helps me<br>
to get the threads together ;)<br>
<span class=""><br>
> <or a couple of years i have been to Zeeland in Autumn and as always i have<br>
> a little time<br>
> to spend on mapping.><br>
><br>
> Great, especially on POI's there's a lot of work left<br>
<br>
</span>Not only pois. Most of the map around here hasnt been touched since the original AND<br>
import. Still a lot of broken highway=pedestrian etc. What i found:<br>
<br>
- A lot and i really a LOT of landuse topology errors. Layered over each other<br>
without any method i can find. Mixing of landuse and highway nodes e.g..<br>
Sometimes single trees as a landuse=forest in the middle of the city.<br>
- Use of landuse=farm where landuse=farmland would be right.<br>
- highway=pedestrian for highway=service or path/foot/bicycle type roads.<br>
- highway=unclassified everywhere - no residential in the citys.<br>
- Strange highway name changes - Sometimes not at the crossing but 10m after which<br>
can not be found on ground.<br>
- A lot of very strange oneways for which some i verified to be non existant.<br>
<span class=""><br></span></blockquote><div><br></div><div>Sounds, unfortunately, familiar. Since I'm focussing on routing for motor vehicles, I've updated thousands of errors which will cause problems for a routing engine. Most of them top-down, that is starting with motorways. I checked almost every motorway in the Netherlands. Still problems there though, because the tags for a lane assistant are just about 90% defined, due to lack of cooperation from developers of routing apps.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> <Are you planning to move the addresses on the appropriate building<br>
> outlines?><br>
><br>
> No. Since the address nodes are in the proximity of the entrance that would<br>
> substantially lower the quality<br>
<br>
</span>Okay - so i dont move nodes except where it makes sense to an entrance on the<br>
building outline.<br>
<span class=""><br>
> There's no special local preference, so the standard OSM practice applies.<br>
> In the case of one building/one POI I add all information (including<br>
> address info) to the building outline ánd I prefer to put the entrance node<br>
> on the building outline. In the case of one building/multiple POI's I put<br>
> all POI info in a node.<br>
<br>
</span>I am just asking before breaking stuff the NL community has agreed to handle<br>
differently.<br>
<span class=""><br>
> <What about strange buildings from the BAG import? I have a couple cases<br>
> where<br>
> the building outline does not at all match the building in a mapbox sat<br>
> imagery.><br>
><br>
> The BAG should contain the correct building outline, since this is<br>
> Cadastral information, nowadays updated very often. But as any database,<br>
> the BAG might incidentally have errors. Satellite imagery though is at risk<br>
> of being well outdated. So in these cases it's possibly best to have groun<br>
> truth info to determine the correct building outline.<br>
<br>
</span>I have found buildings which have a start_date of 2014 and are not orthogonal<br>
and dont match the sat imagery. Yes - i'll have a look whether its a new construction<br>
but the data looks like a 5 year old drew something in EPSG:4326<br>
<br>
Example:<br>
<a href="http://osm.org/go/0EmBaMKXz--?m=" target="_blank">http://osm.org/go/0EmBaMKXz--?m=</a><br>
<span class=""><br></span></blockquote><div><br></div><div>That's a building which will be opened this December:</div><div><a href="http://dagvandebouw.nl/waar/zeeland/nieuwbouw-42-zorgappartementen-svrz-middelburg/">http://dagvandebouw.nl/waar/zeeland/nieuwbouw-42-zorgappartementen-svrz-middelburg/</a><br></div><div><br></div><div>The BAG uses various statuses: the building will be measured after it's finished, which can lead to changes in the outline. Challenge for us as a community is to update the building once the outline is changed in the BAG. Up till now groundtruth is needed to know changes and to do a fresh import of the BAG (minimum import size is one node or one building). Hopefully in the future - depending on availability of programming experience - it will be possible to compare OSM building and address data to the BAG data more efficiently.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> <I also found a BAG imported underground parking which is rendered very<br>
> prominent<br>
> on the map. From looking at the data i have the feeling that a layer=-1<br>
> should<br>
> at least be added but.><br>
><br>
> I agree., all underground buildings should have had layer -x<br>
<br>
</span>And in case of parking i am not shure its a wise decision to actually import it.<br>
<br>
Example:<br>
<a href="http://osm.org/go/0EmByK~r8-?m=" target="_blank">http://osm.org/go/0EmByK~r8-?m=</a><br>
<br>
This building complex looks very strange surrounded by some colored area. Yes i know<br>
we shouldnt care on the actual rendering.<br>
<span class=""><br></span></blockquote><div><br></div><div>I wouldn't mind <a href="http://osm.org">osm.org</a> to be updated with a button: hide underground buildings. We have discussed these kind of buildings and decided to add them. Because they are buildings, only underground. Sometimes a different colour would also help (see for example this subway station I imported: <a href="http://www.openstreetmap.org/#map=19/51.91226/4.46615&layers=N">http://www.openstreetmap.org/#map=19/51.91226/4.46615&layers=N</a>) </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> <What about the "and" tags from the original import? What about correcting<br>
> the landuse stuff from the original import (landuse=farm -> farmland etc)<br>
> and all the topology errors with overlapping landuses.><br>
><br>
> I always remove tags like AND_nosr. Of the hours I spend on OSM most are<br>
> updating routing errors and POI's. But maybe others are working on landuse<br>
> errors.<br>
<br>
</span>Could we possibly add this to josm standard list of discardableKeys? Then those<br>
tags will vanish whenever somebody touches an object.<br>
<br>
Like this:<br>
<br>
diff --git a/src/org/openstreetmap/josm/data/osm/OsmPrimitive.java b/src/org/openstreetmap/josm/data/osm/OsmPrimitive.java<br>
index 62d5f90..2fbb28c 100644<br>
--- a/src/org/openstreetmap/josm/data/osm/OsmPrimitive.java<br>
+++ b/src/org/openstreetmap/josm/data/osm/OsmPrimitive.java<br>
@@ -691,7 +691,8 @@ public abstract class OsmPrimitive extends AbstractPrimitive implements Comparab<br>
"yh:STRUCTURE",<br>
"yh:TOTYUMONO",<br>
"yh:TYPE",<br>
- "yh:WIDTH_RANK"<br>
+ "yh:WIDTH_RANK",<br>
+ "AND_nosr_r"<br>
));<br>
}<br>
return discardable;<br>
<br>
<br>
What about AND:importance_level?<br>
<div class=""><div class="h5"><br></div></div></blockquote><div><br></div><div>You are writing things of which I understand the goal but not the content (I don't have any clue about programming)</div><div>Yes, I would love to have that in JOSM, as well as AND:importance_level, AND_nodes and AND_nosr_p</div><div><br></div><div>If I post a message on the Dutch forum that JOSM will remove these tags, would you be so kind to add this to JOSM?</div><div><br></div><div>Cheers, Johan</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">
Flo<br>
--<br>
Florian Lohoff <a href="mailto:f@zz.de">f@zz.de</a><br>
</div></div><br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
<br>
iQIVAwUBVDGf7ZDdQSDLCfIvAQqgzw//arYsA0SmMfHmlF/MSkBD9GYlzsA7uQP0<br>
ktA7ZgGY8WA85me8H5Mxpk08LdLcaCCPmiCNTebXrRYByGln1K93ydr9mz/PWh8t<br>
I/PaoNEwFR68f83GPDy/DHiqy1E/FlETno0F5VbHwf3upv7744kGKlEsOqtb/qYY<br>
/xVQ5Au74ORTfrmA12ZyswtFfAx3Q2AdeUZ54oMPN4F/LXc1ml7HCg/60Y6Pj38g<br>
owon+gpaGfskLwPa6urLMWrYs7/SUHgH8cyO8l/HKnWvAbzFjVWHhDk+aOlQBdCj<br>
WpzJJxL1SB1ILdIK0Ag+5+7zB0H2EgqbzRrG7o8vxPJ8WqAf9Xj9pPb1XIm/fCPg<br>
g0nakoTbKA9KSpUMVHn547rflWgJfpFAXfHzqmV/xr39ea4zubRYRzF91UCgbTI7<br>
CcCIvUW40zJZSy+HesQ4grwsd/raER/XLSQ2MVC1keYKvKzt7LP9fbh38YdHks7U<br>
JWMLk1uXZTolW/TOyiFUiRfAH9m2wIKmN2WKYWFOT2wk5E0fxD+lnq2TSmQj+CW6<br>
hxOWPsdZGQCGWJ+F4pBdFjVzSRS//BIwYzoUkZgDHlI6P2BxzukhBnbMiKk9QYEU<br>
tVpj0QQIfeNh+pY+MIcB2cvr7TsSuZWDy6i7FArWIQbou33n0pGCVblROiHI3X93<br>
wb73IuWXksw=<br>
=1s2P<br>
-----END PGP SIGNATURE-----<br>
<br>_______________________________________________<br>
Talk-nl mailing list<br>
<a href="mailto:Talk-nl@openstreetmap.org">Talk-nl@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-nl" target="_blank">https://lists.openstreetmap.org/listinfo/talk-nl</a><br>
<br></blockquote></div><br></div></div>