Re: [OSM-talk-be] Agiv import

[Glenn Plas]

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= 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  wrote:
>> On 25-01-16 19:38, Marc Gemis wrote:
>>> On Mon, Jan 25, 2016 at 6:50 PM, Glenn Plas  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

Re: [OSM-talk-be] Agiv import

[Glenn Plas]

On 26-01-16 05:33, Marc Gemis wrote:
> On Tue, Jan 26, 2016 at 1:48 AM, Glenn Plas  wrote:
>> Also, make sure when you create your better OSM bulding, tag it
>> source:geometry=AGIV (I think to recognise agiv sats).
> 
> What do I have to do with source:geometry:date in those cases ?

Don't use this one for manual work.

this applies to the data in fact, so you don't need to manually do this.
 In the dutch BAG import they are using 'ref' but that is more wrong I
believe than what we propose here with the source tags.

wiki:

"If a feature has multiple tags you may want to make use of the source
namespace to indicate precisely which tag your source refers to. For
example:"

So it applies to a date field in the original source (GRB export).

It's similar to the oidn field in fact, you're not going to invent a
number there, it's always in relation with the source data.

Glenn



___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Agiv import

[Marc Gemis]

Thanks for the feedback.

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.

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
?

regards

m

On Tue, Jan 26, 2016 at 1:48 AM, Glenn Plas  wrote:
> On 25-01-16 19:38, Marc Gemis wrote:
>> On Mon, Jan 25, 2016 at 6:50 PM, Glenn Plas  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

Re: [OSM-talk-be] Agiv import

[Marc Gemis]

On Tue, Jan 26, 2016 at 1:48 AM, Glenn Plas  wrote:
> Also, make sure when you create your better OSM bulding, tag it
> source:geometry=AGIV (I think to recognise agiv sats).

What do I have to do with source:geometry:date in those cases ?

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Agiv import

[Glenn Plas]

On 25-01-16 14:06, Marc Gemis wrote:
> What's the planning for the import ?
> 
> * Glenn finishes documentation (although I think it's (almost) ready)

The highlights are ready, but I've encountered plenty of situations that
we will run into that need more detailed documentation.  I've made some
movies as well showing how I worked but I might have to do them again
since I had to change some ways after Sander's valuable input.

The tool isn't quite done yet imho. I still need to fix/improve a few
things in the code.  Also, after-care is important.  I want the script
to also be able to verify if buildings were updated.  Once the GRB
reference (oidn) is in the OSM data we can reference it to compair
(using the source date) if any updates have been done to existing buildings.

> * We pass this somehow through the import mailing list ( I fear we
> cannot avoid this). Sander, you have some experience with this. What
> do you think ?

This needs to pass indeed, but let's not call it an import from now on.
 I prefer a "semi-automated, human reviewed, merge operation" :)
It is a bit like the news calling it a "tactical bombardment" when
blowing up bombs, the first almost sounds like there aren't any
casualties at all.

> * We have a face-to-face meeting / hangout to explain the procedure to
> interested people.  Face-to-face is better I think, but might not be
> feasible for everyone. Perhaps a combination ?

I believe face-2-face is better, and I'm willing to spend time on this,
there are many questions you will have and the interactive approach will
be easier to answer/demonstrate instead of describing it.

> * We start "the import". Somehow we need an overview for this to see
> who is working on a certain town. (a shared document/spreadsheet)

I don't think you really need that in order to be able to work (it
wouldn't hurt though).  Version management will take care of people
working on different areas, in case of conflicts (I had a few where
buildings where updated after my data retrieval from OSM and before
uploading changesets) it's not fun resolving those in JOSM (even hard
sometimes).

So I would suggest doing it in small fractions. I tried 'finding'
building hotspots and just work square per square.  You can also to the
'bijgebouwen' first and then later the main buildings, after that
garages and so on...  So it doesn't have to be segregated into area's ,
you could just do subsets.

The only thing you need to keep track of is the work you've done
yourself.  I deleted the buildings from the source file once I moved
them to the target layer, to avoid duplicate validation work.

The area size was not always as large, it depends on the concentration
of buildings.  We should discuss this at the meeting, because I'm just a
one man show and would love some peer input and feedback.

I was thinking about using HOT osm task manager, it's code is available.
 That would be awesome to

https://github.com/hotosm/osm-tasking-manager2

Then there is also the matter of downloading (Aka `Ordering`) the data.
We should do this 'at once' preferably to make sure adjacent areas match
up. Not doing so might give some problem at the borders of the area.
But that should be minimal.

There are 307 'gemeentes' / general area's in the selection list.  You
can combine some, but I haven't tried to combine all for a full download.

Glenn

> 
> 
> 
> m.
> 
> 
> On Mon, Jan 25, 2016 at 9:55 AM, Glenn Plas  wrote:
>>
>>> I also mean when the geometry in OSM is actually better than in
>>> the GRB. I'm thinking in particular about VIVES in Bruges. The GRB
>>>  building shape is just wrong. In OSM it's better (may be not
>>> perfect, it's a complex building) and 3D mapped.
>>> http://www.openstreetmap.org/#map=18/51.18741/3.20325
>>
>> Yes of course. that's why I call it a merge. since this process
>> encompasses using AGIV sat layer, and GRB layer in JOSM itself, it's
>> not hard to see where GRB has got it wrong.
>>
>> No need to worry about losing good OSM data, when done right..
>>
>> 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

Re: [OSM-talk-be] Agiv import

[Sander Deryckere]

2016-01-25 15:37 GMT+01:00 Glenn Plas :

> On 25-01-16 14:06, Marc Gemis wrote:
> > * We pass this somehow through the import mailing list ( I fear we
> > cannot avoid this). Sander, you have some experience with this. What
> > do you think ?
>
> This needs to pass indeed, but let's not call it an import from now on.
>  I prefer a "semi-automated, human reviewed, merge operation" :)
> It is a bit like the news calling it a "tactical bombardment" when
> blowing up bombs, the first almost sounds like there aren't any
> casualties at all.
>
> I'm confident we'll get through it even when calling it an import. The
data quality is good, we're with a limited set of active mappers (who
worked on OSM long before trying an import), and we care about our region.

The only thing I'd have to defend is the usage of the GRB. They'd need some
guarantee that the key is valid (won't change without a reason, and won't
be reused on another building). I guess the AGIV gives some guarantee for
it in their documentation, but we should make the clear.


> > * We have a face-to-face meeting / hangout to explain the procedure to
> > interested people.  Face-to-face is better I think, but might not be
> > feasible for everyone. Perhaps a combination ?
>
> I believe face-2-face is better, and I'm willing to spend time on this,
> there are many questions you will have and the interactive approach will
> be easier to answer/demonstrate instead of describing it.
>

Face-2-face sounds good.

>
> > * We start "the import". Somehow we need an overview for this to see
> > who is working on a certain town. (a shared document/spreadsheet)
>
> I don't think you really need that in order to be able to work (it
> wouldn't hurt though).  Version management will take care of people
> working on different areas, in case of conflicts (I had a few where
> buildings where updated after my data retrieval from OSM and before
> uploading changesets) it's not fun resolving those in JOSM (even hard
> sometimes).
>
> So I would suggest doing it in small fractions. I tried 'finding'
> building hotspots and just work square per square.  You can also to the
> 'bijgebouwen' first and then later the main buildings, after that
> garages and so on...  So it doesn't have to be segregated into area's ,
> you could just do subsets.
>

Yes, it should be organised in a way you can do an hour or two work on it,
upload it, and return later on with fresh OSM data to avoid conflicts.

>
> The only thing you need to keep track of is the work you've done
> yourself.  I deleted the buildings from the source file once I moved
> them to the target layer, to avoid duplicate validation work.
>
> We could set up a map for this. You can overlay mapbox vector tile
buildings with a GRB background, and see where any GRB buildings stick out,
or the other way around.

We can also use overpass to do some counting in squares or boundaries. F.e.
in Overpass, it would be easy to extract a list of all GRB ids of buildings
in a certain municipality, and compare that with the official data.


> The area size was not always as large, it depends on the concentration
> of buildings.  We should discuss this at the meeting, because I'm just a
> one man show and would love some peer input and feedback.
>
> I was thinking about using HOT osm task manager, it's code is available.
>  That would be awesome to
>
> https://github.com/hotosm/osm-tasking-manager2
>
> Then there is also the matter of downloading (Aka `Ordering`) the data.
> We should do this 'at once' preferably to make sure adjacent areas match
> up. Not doing so might give some problem at the borders of the area.
> But that should be minimal.
>
> There are 307 'gemeentes' / general area's in the selection list.  You
> can combine some, but I haven't tried to combine all for a full download.
>

I ran into the problem of not being able to download it all. My internet
connection isn't stable enough, and when the connection drops, the download
can't be resumed.

But even when you're able to download everything, you should still be able
to split the shapefile. Not all shapefile splitters will work, as some just
run in your memory (and I guess you don't have more than 15 GB RAM).

OSM tasking manager indeed seems like a good idea (it's also used by other
countries to organise imports), and the tasking manager can even provide
links to external files in some way (I've used it when doing an import of
names in Sierra Leone once).

>
> Glenn
>
>
Regards,
Sander
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Agiv import

[Glenn Plas]

On 25-01-16 14:54, Marc Gemis wrote:
> So you are saying a need a couple of weeks more to finalise the tool.

More like a few hours (2/3 hrs). Cleanup the code a bit, perhaps remove
all my chaos inline documentation anchors :)

The verification part (with overpass stuff built in), I can write that
later, it's not too difficult.  Like Sanders state in his most recent
reply: this all depends on the uniqueness and stability of the 'oidn'
reference field, this key is the most important one.

> Then 2-3 weeks discussion on the import mailing list

It could be long, it could go fast too, I don't see us discussing this
too deeply.

> which means we could plan a face-to-face meeting in 2 months ?

For me it's ok to do this sooner, I really don't want to wait another 2
months to start on this, summer is coming and this is going to keep me
inside :)

> 
> I think that planning a face-to-face meeting can start now, so people
> that are interested can keep a day free in their agenda.

I'm setting up the HOT task manager as we speak, it's well documented,
this could be the perfect management tool.  I'll complete the setup asap.

Glenn


___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Agiv import

[Marc Gemis]

What's the planning for the import ?

* Glenn finishes documentation (although I think it's (almost) ready)
* We pass this somehow through the import mailing list ( I fear we
cannot avoid this). Sander, you have some experience with this. What
do you think ?
* We have a face-to-face meeting / hangout to explain the procedure to
interested people.  Face-to-face is better I think, but might not be
feasible for everyone. Perhaps a combination ?
* We start "the import". Somehow we need an overview for this to see
who is working on a certain town. (a shared document/spreadsheet)



m.


On Mon, Jan 25, 2016 at 9:55 AM, Glenn Plas  wrote:
>
>> I also mean when the geometry in OSM is actually better than in
>> the GRB. I'm thinking in particular about VIVES in Bruges. The GRB
>>  building shape is just wrong. In OSM it's better (may be not
>> perfect, it's a complex building) and 3D mapped.
>> http://www.openstreetmap.org/#map=18/51.18741/3.20325
>
> Yes of course. that's why I call it a merge. since this process
> encompasses using AGIV sat layer, and GRB layer in JOSM itself, it's
> not hard to see where GRB has got it wrong.
>
> No need to worry about losing good OSM data, when done right..
>
> 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

Re: [OSM-talk-be] Agiv import

[Marc Gemis]

So you are saying a need a couple of weeks more to finalise the tool.
Then 2-3 weeks discussion on the import mailing list
which means we could plan a face-to-face meeting in 2 months ?

I think that planning a face-to-face meeting can start now, so people
that are interested can keep a day free in their agenda.

m.

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Agiv import

[Marc Gemis]

On Mon, Jan 25, 2016 at 6:50 PM, Glenn Plas  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

https://xian.smugmug.com/OSM/Screenshots/Screenshots-1/i-JS8qrcz
https://xian.smugmug.com/OSM/Screenshots/Screenshots-1/i-74hZpVR

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Agiv import

[Marc Gemis]

On Mon, Jan 25, 2016 at 4:27 PM, Glenn Plas  wrote:
>> which means we could plan a face-to-face meeting in 2 months ?
>
> For me it's ok to do this sooner, I really don't want to wait another 2
> months to start on this, summer is coming and this is going to keep me
> inside :)

fine for me, we could even do this while the discussion on the import
mailing list is going on, not ?
This means that we should start looking for a meeting place and a
date. And we should know who is going to be involved (or wants to be
involved)

m

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Agiv import

[Marc Gemis]

A short question about source:geometry.

Should I/we keep it when we modify the building afterwards. I'm
thinking of the following cases

* In the meantime, part of the building got destroyed
* The building got finished in the meantime
* straighten the corners
* connecting 2 building parts because the part above the
"tunnel=building_passage" is missing
* splitting a building because the garage is clearly separated on AGIV imagery


regards

m

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Agiv import

[Glenn Plas]

Hi Marc,

On 25-01-16 17:05, Marc Gemis wrote:
> A short question about source:geometry.

Feel free to ask

> 
> Should I/we keep it when we modify the building afterwards. I'm
> thinking of the following cases

When I modified a building manually because GRB is not correct, I change
this to source:geometry=AGIV

This way it would be a very simple/lightweight Overpass query to see the
manually adjusted buildings.  This could even serve as a feedback to GRB
itself, as I hate finding errors and mistakes in GRB with no (easy and
fast) way to reporting this.

It's also easy to extend this, source *could* be Bing (although I hope
to never see that in the data), it could be a future source, but any
adjustment made, I would strongly recommend changing that value.  It
could probably be 'Survey' in your case ;-)

The most common error is when only the front side has been measured and
the visible sides (aka , what you can see from standing in the street)

> * In the meantime, part of the building got destroyed
> * The building got finished in the meantime
> * straighten the corners
> * connecting 2 building parts because the part above the
> "tunnel=building_passage" is missing

building passages are actually in the GRB-Gis dataset, often, but not
always it's a 'verdieping' or 'roof'.  I've seen both with a lot more
verdieping's than roofs for building passages.

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

If you want to be complete on buildings, you have to combine at least 3
shape files:

Gbg = main buildings and buildings (OSM types: sheds, garages, house,
churches, hangars, office and so on ...)

Adp = roofs, verdieping (in essence a building), difference between roof
attached(overhang on building) and separate (a free standing gas station
roof)

Knw = So far what I've seen, none of these buildings have a
housenumber/address/street attached. Most often, these buildings are
separated from the rest , but I've seen some that attached to other
buildings.

Knw is the hardest to turn into OSM with a script in fact, I still need
to implement this.  But the amount of buildings in here is small and
none are sporting an address in the datasets I analysed, I find these
less important at this moment.

But combined, they should match the building you see well. Make sure you
compare your building with at least the combined Gbg+Adp GRB version.

But 'too much building'-case in between , I only encountered this when
buildings were obviously destroyed.  Resulting in deleting in entirely.

Do you have an OIDN (and area) of this building? I can take a look at
the data set to understand better.

Glenn


See http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/GRB

> 
> 
> regards
> 
> m
> 
> ___
> 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

Re: [OSM-talk-be] Agiv import

[Glenn Plas]

On 25-01-16 19:38, Marc Gemis wrote:
> On Mon, Jan 25, 2016 at 6:50 PM, Glenn Plas  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

Re: [OSM-talk-be] Agiv import

[Glenn Plas]

> I also mean when the geometry in OSM is actually better than in
> the GRB. I'm thinking in particular about VIVES in Bruges. The GRB
>  building shape is just wrong. In OSM it's better (may be not 
> perfect, it's a complex building) and 3D mapped. 
> http://www.openstreetmap.org/#map=18/51.18741/3.20325

Yes of course. that's why I call it a merge. since this process
encompasses using AGIV sat layer, and GRB layer in JOSM itself, it's
not hard to see where GRB has got it wrong.

No need to worry about losing good OSM data, when done right..

Glenn

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Agiv import

[Ruben Maes]

Sunday 24 January 2016 18:13:02, Jo:
> You could add note on them, but there is no guarantee that it gets read or
> acted upon, so it's probably a waste of bytes to do so. There are tools
> that let you watch over certain areas that have your interest, then you can
> revert and send a message to the person who replaced with inferior data to
> no do so in that region.
> 
> I think that's the more sensible way to proceed, but I can't remember the
> names of those tools at the moment.

Thanks Jo. After some searching I found that 
http://simon04.dev.openstreetmap.org/whodidit/ has such functionality.

-- 
This message is OpenPGP signed.

signature.asc
Description: This is a digitally signed message part.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Agiv import

[Sander Deryckere]

Ruben,

The import is a lot more complicated than the CRAB import, but also less
monkey work, so there will only be a few people doing that import. Normally
those will also be careful about what they import, but they should also be
easy to contact, so you can warn them on beforehand.

However, now it's just in some sort of testing phase, so it's not yet known
who will occupy himself with the import.

Regards,
Sander

2016-01-24 17:48 GMT+01:00 Ruben Maes :

> Thursday 21 January 2016 05:35:11, Marc Gemis:
> > At this moment someone is working on converting the GRB data into
> something
> > that can be "easily" imported.
> > (...)
>
> Great that we'll have a more or less complete map of the buildings in
> Flanders.
>
> I know some places where OSM already has much better building information
> than Agiv, mapped with love and local knowledge. Can I make sure those
> don't get overridden by inferior data with a note in the data or something?
>
> --
> This message is OpenPGP signed.
> ___
> 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

Re: [OSM-talk-be] Agiv import

[Marc Gemis]

As the other pointed out, the import has to be done /will be done
carefully. Glenn try it in a mostly empty area and of course it goes
much faster. In an area with buildings, we will keep all existing
information. The replace geometry functionality in JOSM + utilsplugin2
is your friend.

The quality of the data after the import will depend on the person
that does the import. I noticed, e.g. that many peoples do not have
nice corners. So I did a "q" on them. Maybe other will "forget" that
step. I also removed several additional nodes. I prefer to go a bit
slower, but deliver a nicer result. Others might import more and clean
up less. We see the same with the import of the addresses so far. Some
just draw a bunch of rectangles for the houses, regardless of the
actual shape.

It all depends on your goals.

Depending on the town, you might notice that the data can be a bit of
of date or sometimes it can be drawn a bit clumsy. It's up to the
importer to be alert and fix it IMHO.

I hope we can organize a meetup or a hangout to explain the tools and
the tips and tricks to some people later on.

regards

m

On Sun, Jan 24, 2016 at 5:48 PM, Ruben Maes  wrote:
> Thursday 21 January 2016 05:35:11, Marc Gemis:
>> At this moment someone is working on converting the GRB data into something
>> that can be "easily" imported.
>> (...)
>
> Great that we'll have a more or less complete map of the buildings in 
> Flanders.
>
> I know some places where OSM already has much better building information 
> than Agiv, mapped with love and local knowledge. Can I make sure those don't 
> get overridden by inferior data with a note in the data or something?
>
> --
> This message is OpenPGP signed.
> ___
> 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

Re: [OSM-talk-be] Agiv import

[Marc Gemis]

It's up to the mapper that does the import to check each building individually.
It's not different than noticing that a building is partly destroyed
on the AGIV imagery and adapting the GRB building according to that.

m

On Sun, Jan 24, 2016 at 8:43 PM, Ruben Maes  wrote:
> Sunday 24 January 2016 19:03:35, Glenn Plas:
>> (...)
>> In the whole of Stekene, I probably deleted no more than 20 buildings
>> on multiple thousands that got imported with good reasons.  Deleting
>> is not an issue.
>> (...)
>> Tag migration and merging takes more time than replaceing the geometry
>> itself.  Every time the merge conflict dialog pops up, you'll loose 15
>> seconds, multiply that by thousands of buildings...
>> (...)
>
> I also mean when the geometry in OSM is actually better than in the GRB. I'm 
> thinking in particular about VIVES in Bruges. The GRB building shape is just 
> wrong. In OSM it's better (may be not perfect, it's a complex building) and 
> 3D mapped.
> http://www.openstreetmap.org/#map=18/51.18741/3.20325
>
> --
> This message is OpenPGP signed.
>
> ___
> 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

Re: [OSM-talk-be] Agiv import

[Glenn Plas]

The current test procedure respects previous editing work, because the
goal is not to import GRB data (not = CRAB) into OSM, but to improve
OSM data with GRB.

That means keeping history on an existing building intact, taking into
account that a human has entered the original tags in case of doubt,
the editor needs to decide what's appropriate.

In the whole of Stekene, I probably deleted no more than 20 buildings
on multiple thousands that got imported with good reasons.  Deleting
is not an issue.

What will be a challenge is training and guidance in a working
procedure, making sure we take acceptable decisions in area's of conflict.

It will also never be fully automated due to the fact that it's not
going to be a flat import but more like a merger of data.

The speed is depending on how much conflict you encounter, existing
buildings are not a problem, but it's indeed easier and faster when
nothing is 'in the way' . But even in crowded places where houses
existed, merging a building just takes 100% attention, a few seconds
and a lot of coffee on the side.

Existing data actually helps on deciding.  The real time consuming
bit's are when existing buildings were addressed incorrectly in OSM
(offset housenumbers by 1 building -for example- is a pain in the butt)

Tag migration and merging takes more time than replaceing the geometry
itself.  Every time the merge conflict dialog pops up, you'll loose 15
seconds, multiply that by thousands of buildings...

I believe that crowded cities will be intensive to merge.

Glenn



On 24-01-16 18:18, Marc Gemis wrote:
> As the other pointed out, the import has to be done /will be done
> carefully. Glenn try it in a mostly empty area and of course it goes
> much faster. In an area with buildings, we will keep all existing
> information. The replace geometry functionality in JOSM + utilsplugin2
> is your friend.
> 
> The quality of the data after the import will depend on the person
> that does the import. I noticed, e.g. that many peoples do not have
> nice corners. So I did a "q" on them. Maybe other will "forget" that
> step. I also removed several additional nodes. I prefer to go a bit
> slower, but deliver a nicer result. Others might import more and clean
> up less. We see the same with the import of the addresses so far. Some
> just draw a bunch of rectangles for the houses, regardless of the
> actual shape.
> 
> It all depends on your goals.
> 
> Depending on the town, you might notice that the data can be a bit of
> of date or sometimes it can be drawn a bit clumsy. It's up to the
> importer to be alert and fix it IMHO.
> 
> I hope we can organize a meetup or a hangout to explain the tools and
> the tips and tricks to some people later on.
> 
> regards
> 
> m
> 
> On Sun, Jan 24, 2016 at 5:48 PM, Ruben Maes  wrote:
>> Thursday 21 January 2016 05:35:11, Marc Gemis:
>>> At this moment someone is working on converting the GRB data into something
>>> that can be "easily" imported.
>>> (...)
>>
>> Great that we'll have a more or less complete map of the buildings in 
>> Flanders.
>>
>> I know some places where OSM already has much better building information 
>> than Agiv, mapped with love and local knowledge. Can I make sure those don't 
>> get overridden by inferior data with a note in the data or something?
>>
>> --
>> This message is OpenPGP signed.
>> ___
>> 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

Re: [OSM-talk-be] Agiv import

[Ruben Maes]

Sunday 24 January 2016 19:03:35, Glenn Plas:
> (...)
> In the whole of Stekene, I probably deleted no more than 20 buildings
> on multiple thousands that got imported with good reasons.  Deleting
> is not an issue.
> (...)
> Tag migration and merging takes more time than replaceing the geometry
> itself.  Every time the merge conflict dialog pops up, you'll loose 15
> seconds, multiply that by thousands of buildings...
> (...)

I also mean when the geometry in OSM is actually better than in the GRB. I'm 
thinking in particular about VIVES in Bruges. The GRB building shape is just 
wrong. In OSM it's better (may be not perfect, it's a complex building) and 3D 
mapped.
http://www.openstreetmap.org/#map=18/51.18741/3.20325

-- 
This message is OpenPGP signed.

signature.asc
Description: This is a digitally signed message part.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be