[OSM-talk-nl] Netherland mapping for Tourists / Adress nodes move to building etc

Johan C osmned at gmail.com
Sun Oct 5 20:36:23 UTC 2014


Hey Florian

2014-10-05 21:45 GMT+02:00 Florian Lohoff <f at zz.de>:

>
> 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.
>
>
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.


> > <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=
>
>
That's a building which will be opened this December:
http://dagvandebouw.nl/waar/zeeland/nieuwbouw-42-zorgappartementen-svrz-middelburg/

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.

> <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.
>
>
I wouldn't mind osm.org 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:
http://www.openstreetmap.org/#map=19/51.91226/4.46615&layers=N)


> > <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?
>
>
You are writing things of which I understand the goal but not the content
(I don't have any clue about programming)
Yes, I would love to have that in JOSM, as well as AND:importance_level,
AND_nodes and AND_nosr_p

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?

Cheers, Johan



> Flo
> --
> Florian Lohoff                                                 f at zz.de
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIVAwUBVDGf7ZDdQSDLCfIvAQqgzw//arYsA0SmMfHmlF/MSkBD9GYlzsA7uQP0
> ktA7ZgGY8WA85me8H5Mxpk08LdLcaCCPmiCNTebXrRYByGln1K93ydr9mz/PWh8t
> I/PaoNEwFR68f83GPDy/DHiqy1E/FlETno0F5VbHwf3upv7744kGKlEsOqtb/qYY
> /xVQ5Au74ORTfrmA12ZyswtFfAx3Q2AdeUZ54oMPN4F/LXc1ml7HCg/60Y6Pj38g
> owon+gpaGfskLwPa6urLMWrYs7/SUHgH8cyO8l/HKnWvAbzFjVWHhDk+aOlQBdCj
> WpzJJxL1SB1ILdIK0Ag+5+7zB0H2EgqbzRrG7o8vxPJ8WqAf9Xj9pPb1XIm/fCPg
> g0nakoTbKA9KSpUMVHn547rflWgJfpFAXfHzqmV/xr39ea4zubRYRzF91UCgbTI7
> CcCIvUW40zJZSy+HesQ4grwsd/raER/XLSQ2MVC1keYKvKzt7LP9fbh38YdHks7U
> JWMLk1uXZTolW/TOyiFUiRfAH9m2wIKmN2WKYWFOT2wk5E0fxD+lnq2TSmQj+CW6
> hxOWPsdZGQCGWJ+F4pBdFjVzSRS//BIwYzoUkZgDHlI6P2BxzukhBnbMiKk9QYEU
> tVpj0QQIfeNh+pY+MIcB2cvr7TsSuZWDy6i7FArWIQbou33n0pGCVblROiHI3X93
> wb73IuWXksw=
> =1s2P
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Talk-nl mailing list
> Talk-nl at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-nl/attachments/20141005/32023e4c/attachment.htm>


More information about the Talk-nl mailing list