Hey Florian 2014-10-05 21:45 GMT+02:00 Florian Lohoff <[email protected]>:
> > 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 [email protected] > > -----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 > [email protected] > https://lists.openstreetmap.org/listinfo/talk-nl > >
_______________________________________________ Talk-nl mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-nl
