On 26-01-16 04:27, Marc Gemis wrote: > Thanks for the feedback. My pleasure. Thanks for discussing and questioning this, this is good.
> > I seems like I always stumble upon cases like this (also with De Lijn, > house numbers, Dutch import). So no surprise that I am critical about > "imports" (or manually merged data from another DB). With your > procedure we can avoid that such data creeps into OSM, but you have to > be careful and not hurry the data merger to much. Haste is bad, but speed is good. I would love to get this done by SOTM 2016 :) > Do we really need the source=GRB tag ? (not talking about > source:geometry). I don't like this tag (source) anymore. They are not > maintained, it's not clear to which part of the tags they apply and > just fill the database. When you survey a POI e.g., the name and type > of shop come from the picture you have taken, the position from the > georeferencing of the photo, combined with your memory and aerial > image, the building layout comes from AGIV (or GRB), the house number > from survey/GRB/CRAB, the webpage from a web search, etc. What is > source in that case ? Are you adding source:XXX for each different tag Yes it's a requirement. You need source=* when you have other source subkeys according to wiki. JOSM will also complain if you lack source=<something> normally and have other source subkeys. Besides that, it makes sense too. The buildings (meta) datasource (GRB) can be different than the geometry (agiv). During my research this was the case, but I just tried to reproduce this and JOSM doesn't warn me anymore. Have to figure out why and what combination throws warnings. But rest assured, I've done quite some homework on the source tag, I think this is how 'minimal' we can get with the tags. This source tag actually applies on the important metadata imho. So if you have source references like oidn and date now, we want to mention where that came from through the source tag. But I hear you on the mixed sources dilema. For me , once the oidn source tag is present on the way, that would default to source=GRB, it's important because it informs the next mapper to take into account it came from a trustworthy source. it helps the decision process: "when you want to change something, better make sure you doublecheck" Glenn > ? > > regards > > m > > On Tue, Jan 26, 2016 at 1:48 AM, Glenn Plas <gl...@byte-consult.be> wrote: >> On 25-01-16 19:38, Marc Gemis wrote: >>> On Mon, Jan 25, 2016 at 6:50 PM, Glenn Plas <gl...@byte-consult.be> wrote: >>>>> * splitting a building because the garage is clearly separated on AGIV >>>>> imagery >>>> >>>> You should not have to do that imho, I've never encountered this 'too >>>> much building in between' situation. When the garage is separated >>>> visibly on sat images but not in GRB, that's a precarious case, it could >>>> be that the building has been replaced but GRB isn't up to date, it >>>> could also be that the sat pics used are out of date and there has been >>>> an additional construction already in GRB. You can't tell now what is >>>> correct from combining al sources of information. >>> >>> It's in Kaprijke, oid 1964089 IMHO this is just sloppy work in GRB. >>> For those without access to GRB >> >> Absolutely right, it should be more like the neighbour’s house+garage. >> That is some really shitty data you have in that area there. Someone >> really didn't bother being accurate. They aren't even decent squares. >> >> These cases I've only seen a few of those. I specifically remember a >> building crossing itself, like a closed '8' instead of an '0' or open 8 >> like here (bit of imagination applies) >> >> I would remove that corner from the main building, draw the garage >> yourself, tag it appropriately. The garage should in fact have it's own >> OIDN number in GRB data. >> >> Also, make sure when you create your better OSM bulding, tag it >> source:geometry=AGIV (I think to recognise agiv sats). >> >> Then whenever this gets into GRB and trickles down in OSM, you will get >> a merge pop-up here (because we use source:geometry=GRB for our building >> imports by default), instead of a silent merge... you'll get notified >> there is a conflict, forcing you (=editor) to make a judgement call. >> >> Looks like pretty recent buildings. Sloppy fieldwork indeed. >> >> It sure varies a lot the quality, probably by the decentralised approach >> to this. >> >> >> Nice catch. >> >> Glenn >> >> _______________________________________________ >> Talk-be mailing list >> Talk-be@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-be > > _______________________________________________ > Talk-be mailing list > Talk-be@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-be > _______________________________________________ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
