Hi Johan,
On Sun, Oct 05, 2014 at 04:49:15PM +0200, Johan C wrote:
Hi Florian
I invite you to make comments on the OpenStreetMap forum (
http://forum.openstreetmap.org/viewforum.php?id=12) because there's more
Dutch mappers active there. Awaiting your input there, I'll already do a
short reply to you,
Hmm i am not the kind of Forum user. I like my email program which helps me
to get the threads together ;)
<or a couple of years i have been to Zeeland in Autumn and as always i have
a little time
to spend on mapping.>
Great, especially on POI's there's a lot of work left
Not only pois. Most of the map around here hasnt been touched since the
original AND
import. Still a lot of broken highway=pedestrian etc. What i found:
- A lot and i really a LOT of landuse topology errors. Layered over each other
without any method i can find. Mixing of landuse and highway nodes e.g..
Sometimes single trees as a landuse=forest in the middle of the city.
- Use of landuse=farm where landuse=farmland would be right.
- highway=pedestrian for highway=service or path/foot/bicycle type roads.
- highway=unclassified everywhere - no residential in the citys.
- Strange highway name changes - Sometimes not at the crossing but 10m after
which
can not be found on ground.
- A lot of very strange oneways for which some i verified to be non existant.
<Are you planning to move the addresses on the appropriate building
outlines?>
No. Since the address nodes are in the proximity of the entrance that would
substantially lower the quality
Okay - so i dont move nodes except where it makes sense to an entrance on the
building outline.
There's no special local preference, so the standard OSM practice applies.
In the case of one building/one POI I add all information (including
address info) to the building outline ánd I prefer to put the entrance node
on the building outline. In the case of one building/multiple POI's I put
all POI info in a node.
I am just asking before breaking stuff the NL community has agreed to handle
differently.
<What about strange buildings from the BAG import? I have a couple cases
where
the building outline does not at all match the building in a mapbox sat
imagery.>
The BAG should contain the correct building outline, since this is
Cadastral information, nowadays updated very often. But as any database,
the BAG might incidentally have errors. Satellite imagery though is at risk
of being well outdated. So in these cases it's possibly best to have groun
truth info to determine the correct building outline.
I have found buildings which have a start_date of 2014 and are not orthogonal
and dont match the sat imagery. Yes - i'll have a look whether its a new
construction
but the data looks like a 5 year old drew something in EPSG:4326
Example:
http://osm.org/go/0EmBaMKXz--?m=
<I also found a BAG imported underground parking which is rendered very
prominent
on the map. From looking at the data i have the feeling that a layer=-1
should
at least be added but.>
I agree., all underground buildings should have had layer -x
And in case of parking i am not shure its a wise decision to actually import it.
Example:
http://osm.org/go/0EmByK~r8-?m=
This building complex looks very strange surrounded by some colored area. Yes i
know
we shouldnt care on the actual rendering.
<What about the "and" tags from the original import? What about correcting
the landuse stuff from the original import (landuse=farm -> farmland etc)
and all the topology errors with overlapping landuses.>
I always remove tags like AND_nosr. Of the hours I spend on OSM most are
updating routing errors and POI's. But maybe others are working on landuse
errors.
Could we possibly add this to josm standard list of discardableKeys? Then those
tags will vanish whenever somebody touches an object.
Like this:
diff --git a/src/org/openstreetmap/josm/data/osm/OsmPrimitive.java
b/src/org/openstreetmap/josm/data/osm/OsmPrimitive.java
index 62d5f90..2fbb28c 100644
--- a/src/org/openstreetmap/josm/data/osm/OsmPrimitive.java
+++ b/src/org/openstreetmap/josm/data/osm/OsmPrimitive.java
@@ -691,7 +691,8 @@ public abstract class OsmPrimitive extends
AbstractPrimitive implements Comparab
"yh:STRUCTURE",
"yh:TOTYUMONO",
"yh:TYPE",
- "yh:WIDTH_RANK"
+ "yh:WIDTH_RANK",
+ "AND_nosr_r"
));
}
return discardable;
What about AND:importance_level?
Flo
_______________________________________________
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl
