Re: [Talk-ca] Importing buildings in Canada

[Tim Elrick]

I would assume in most cases the imported building footprint will be 
more precise than existing data. For me, this would be a reason to 
replace already existing objects. However, I think this is a case by 
case decision. However, I think it is important to keep tags and history 
of buildings already existent in OSM. This is how I would read/interpret 
the import guideline stated by Nate: "If you are importing data where 
there is already some data in OSM, then *you need to combine this data* 
in an appropriate way or suppress the import of features with overlap 
with existing data." (emphasis added by me)


However, that just means, the import, hence, is nothing easy and could 
not be achieve quickly, I would assume. One way of making sure that this 
is dealt with diligently, would be setting the tasking manager to 
'experienced mappers only'. We would have to ask James, who is in charge 
of the Canada Tasking Manager, how to edit/set up the 'experienced 
mapper role' in the TM. It might be possible to feed in a list of 
mappers manually or to set a threshold of objects/changesets that they 
must have entered in OSM. However, maybe only mappers who feel 
experienced enough to handle the import would contribute to the TM 
project anyway and we let everyone judge on their own and don't restrict 
access.


If we were to separate the new and overlapping buildings, I am also 
leaning towards Daniel's assessment. I would be afraid to cause more 
issues than by doing it all at once (with a reasonable tile size, of 
course).


In the end, the main point of importing this specific dataset fulfils 
two purposes, in my opinion: first, to add missing buildings (if it were 
just for this purpose we could also use the much bigger Microsoft 
dataset), second, to get the best geospatial representation possible in 
our OSM database. That means, we defer from using the Microsoft dataset 
and use the much higher quality data from the ODB. This also means that 
we should replace already existing buildings (yet keeping tags and 
history) wherever the ODB footprint is more precise than the existing one.


Just my two cents here,
Tim

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

Re: [Talk-ca] Building tags in Canada

[stevea]

On Jan 16, 2020, at 3:56 PM, john whelan  wrote:
> I think what is in the wiki is a sort of dream.  An accurate building date 
> for example is often difficult to determine. but probably it needs a sort of 
> low hanging fruit section of what should be easy to tag.

One of the best parts of an open data collaboration like OSM is that "dreamy 
goals" are sometimes (even often?) posited, then pretty darn good results come 
from people picking and choosing from a large menu what interests them,   hat 
works for them, what is relevant to them (and their knowledge and the data and 
the structure into which all of this is poured).  It doesn't have to be 
all-or-nothing, in fact, it shouldn't be:  the "one brick at a time" approach 
is largely how our map has been built so far.

If the wiki is too dreamy to use as a wiki now, I might suggest it (or whatever 
consensus-based documentation of "how we do this" IS being used) be whacked 
down to where it IS realistic.  One benefit from doing so is that low-hanging 
fruit, on a short menu, looks that much easier to achieve towards completion, 
and therefore might even make great results MORE likely to be achieved.

Cheers,
SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building tags in Canada

[john whelan]

That sort of works but doesn't include roof:levels.

The easy tag would be building=detached but then you get building=house
which can be used for a semi detached house.

Locally we have some split levels so a single floor at ground level then a
garage often slightly sunk with another room or two on top.
building:levels=?

I'm tempted by the idea of using Streetcomplete's set of suggested tags.

Postcode is fine if you know it but it isn't always obvious from looking at
the building on the outside.

I think what is in the wiki is a sort of dream.  An accurate building date
for example is often difficult to determine. but probably it needs a sort
of low hanging fruit section of what should be easy to tag.

Thanks John

On Thu, 16 Jan 2020 at 17:49, stevea  wrote:

> On Jan 16, 2020, at 2:37 PM, John Whelan  wrote:
> > Is there somewhere that offers guidelines on how to add additional tags?
> and which tags are more interesting and which should be avoided?   For
> example country=Canada is probably superfluous.
>
> As it hasn't been touched in five months, I'm not sure how applicable the
> wiki
>
>
> https://wiki.osm.org/wiki/Canada/Building_Canada_2020#The_data_that_could_be_mapped
>
> is, relevant to how "this" is being done today.  This effort's wikis and
> approaches have changed — and grown!— since that document was drafted.
>
> But, that section does indicate that OSM's "key building=* currently has
> over 60 documented values" and the "man_made=* key now has over 50
> documented values."  I do recall when I selected eight or ten of the values
> noted there that I was largely making educated guesses.  But now, as is
> true of wiki, especially during a project that is still sort of "wet cement
> being mixed" (nothing wrong with that, it has to happen, it happens well
> now) please feel free to modify these values as you see fit.  It was meant
> to be a starting point, may you continue with it as well as possible.  (Or
> not).
>
> SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building tags in Canada

[stevea]

On Jan 16, 2020, at 2:37 PM, John Whelan  wrote:
> Is there somewhere that offers guidelines on how to add additional tags? and 
> which tags are more interesting and which should be avoided?   For example 
> country=Canada is probably superfluous.

As it hasn't been touched in five months, I'm not sure how applicable the wiki

https://wiki.osm.org/wiki/Canada/Building_Canada_2020#The_data_that_could_be_mapped

is, relevant to how "this" is being done today.  This effort's wikis and 
approaches have changed — and grown!— since that document was drafted.

But, that section does indicate that OSM's "key building=* currently has over 
60 documented values" and the "man_made=* key now has over 50 documented 
values."  I do recall when I selected eight or ten of the values noted there 
that I was largely making educated guesses.  But now, as is true of wiki, 
especially during a project that is still sort of "wet cement being mixed" 
(nothing wrong with that, it has to happen, it happens well now) please feel 
free to modify these values as you see fit.  It was meant to be a starting 
point, may you continue with it as well as possible.  (Or not).

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

[Talk-ca] Building tags in Canada

[John Whelan]

Part of the building import was the idea that once an outline was in 
place it could be tagged with more detail by someone with local 
knowledge. Sometimes some of this this information might be available 
from Mapillary.


For example building=house rather than building=yes

In Coburg there are a number of buildings labelled roof:levels=1

My understanding is this means a room in the attic which is fine but if 
you'd noted the attic room would it not make sense to map the number of 
levels as well?


Is there somewhere that offers guidelines on how to add additional tags? 
and which tags are more interesting and which should be avoided?   For 
example country=Canada is probably superfluous.


Thanks John

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

Re: [Talk-ca] FW: Re: Importing buildings in Canada

[Nate Wessel]

Daniel,

The section you cite from the import guidelines seems to support my 
position. Perhaps that means I haven't explained my thoughts well? It says:


"If you are importing data where there is already some data in OSM, then 
you need to combine this data in an appropriate way or suppress the 
import of features with overlap with existing data. Only where you have 
explicit support, which is highly unusual, should you replace current 
data with your imported data."


OSM is not all that dynamic - if it was, we wouldn't be talking about an 
import. We should do our best to align the data we're thinking of 
bringing in with gaps in the existing data. That's what conflation is 
all about. We should not systematically change existing data. That's 
called an automated edit and is governed by different policies than an 
import.


I'm not saying any plan is perfect - there will be gaps and overlaps, of 
course. But that doesn't mean we don't try at all.


Toronto has hundreds of thousands of buildings in OSM. They are not 
going to be compared manually, one by one if there is an import.


--

And again, I'm not saying not to do explicit building conflation and 
check for updated geometries - I'm just saying that it needs to be a 
separate process if it happens.


Best,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com 

On 2020-01-16 2:56 p.m., Daniel @jfd553 wrote:


Hello Nate,

I understand that you don’t like to see an import process that both 
bring in new objects and overwrite existing ones. You also suggest 
removing "overlapped" building from ODB prior to import it. Such 
pre-processing, that would ensure there will be no buildings 
"overwrite" during the import, is not realistic (i.e. you will need to 
overwrite some buildings anyway). Here are two reasons why it would be 
difficult...


1-OSM is a dynamic project and, unless you can "clean" the data on the 
fly, you will end up with overlaps since some contributors will have 
added buildings in the meantime.


2-One cannot assume that an OSM building, and its ODB counterpart, 
will be found at the same location (look at DX and DY columns in ODB 
inventory tables). These are averages, which means there are larger 
offsets between both datasets (i.e. you won’t get a match between 
buildings, or get a match with the wrong ones).


The only realistic option is then to manually delete the ODB buildings 
if they overlap OSM ones. Here is what the import guideline suggests [1]…


"If you are importing data where there is already some data in OSM, 
then you need to combine this data in an appropriate way or suppress 
the import of features with overlap with existing data."


Therefore, importing data and using a conflation process is not 
unusual. Again, I understand that in case of an overlap, you go for 
the last option (suppress the import building). I am rather inclined 
toward using conflation when necessary, which means...


-Importing an ODB building when there is no corresponding one in OSM;

-Conflating both ODB and OSM buildings when it significantly improves 
existing OSM content;


-Not importing an ODB building when the corresponding one in OSM is 
adequate.


What do the others on the list think?

Daniel

[1] 
https://wiki.openstreetmap.org/wiki/Import/Guidelines#Don.27t_put_data_on_top_of_data


*From:*Nate Wessel [mailto:bike...@gmail.com]
*Sent:* Thursday, January 16, 2020 10:38
*To:* Daniel @jfd553; talk-ca@openstreetmap.org
*Subject:* Re: [Talk-ca] FW: Re: Importing buildings in Canada

Responding to point C below,
I would strongly suggest that we not confuse the process of importing 
new data with that of updating/modifying existing data in the OSM 
database. One of the things I really disliked about the initial 
building import was that it overwrote existing data at the same time 
that new data was brought in. These are really two separate import 
processes and require very different considerations.


We can certainly consider using this dataset to improve/update 
existing building geometries, but I think that is a separate process 
from the import we are discussing here. To keep things simple for this 
import, I would suggest removing any building from the import dataset 
that intersects with an existing building in the OSM database. That 
is, let's not worry about conflation for now, and come back and do 
that work later if we still feel there is a strong need for it.


I see the main point of this effort as getting more complete coverage 
- it we want to use the dataset to do quality assurance on existing 
data, that is a whole other discussion.


Best,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com 

On 2020-01-15 12:55 p.m., Daniel @jfd553 wrote:

Thanks for the quick replies!

Now, about...

*a) Data hosting:*

Thank you James, I really appreciate your offer (and that of
others). So yes, I think hosting pre-pro

Re: [Talk-ca] FW: Re: Importing buildings in Canada

[john whelan]

My understanding is that is when we imported Ottawa we followed the normal
process as detailed by Daniel and that seemed to work quite nicely.

Cheerio John

On Thu, Jan 16, 2020, 2:57 PM Daniel @jfd553,  wrote:

> Hello Nate,
>
> I understand that you don’t like to see an import process that both bring
> in new objects and overwrite existing ones. You also suggest removing
> "overlapped" building from ODB prior to import it. Such pre-processing,
> that would ensure there will be no buildings "overwrite" during the import,
> is not realistic (i.e. you will need to overwrite some buildings anyway).
> Here are two reasons why it would be difficult...
>
> 1-  OSM is a dynamic project and, unless you can "clean" the data on
> the fly, you will end up with overlaps since some contributors will have
> added buildings in the meantime.
>
> 2-  One cannot assume that an OSM building, and its ODB counterpart,
> will be found at the same location (look at DX and DY columns in ODB
> inventory tables). These are averages, which means there are larger offsets
> between both datasets (i.e. you won’t get a match between buildings, or get
> a match with the wrong ones).
>
> The only realistic option is then to manually delete the ODB buildings if
> they overlap OSM ones. Here is what the import guideline suggests [1]…
>
> "If you are importing data where there is already some data in OSM, then
> you need to combine this data in an appropriate way or suppress the import
> of features with overlap with existing data."
>
> Therefore, importing data and using a conflation process is not unusual.
> Again, I understand that in case of an overlap, you go for the last option
> (suppress the import building). I am rather inclined toward using
> conflation when necessary, which means...
>
> -  Importing an ODB building when there is no corresponding one
> in OSM;
>
> -  Conflating both ODB and OSM buildings when it significantly
> improves existing OSM content;
>
> -  Not importing an ODB building when the corresponding one in
> OSM is adequate.
>
> What do the others on the list think?
>
> Daniel
>
> [1]
> https://wiki.openstreetmap.org/wiki/Import/Guidelines#Don.27t_put_data_on_top_of_data
>
>
>
>
>
> *From:* Nate Wessel [mailto:bike...@gmail.com]
> *Sent:* Thursday, January 16, 2020 10:38
> *To:* Daniel @jfd553; talk-ca@openstreetmap.org
> *Subject:* Re: [Talk-ca] FW: Re: Importing buildings in Canada
>
>
>
> Responding to point C below,
> I would strongly suggest that we not confuse the process of importing new
> data with that of updating/modifying existing data in the OSM database. One
> of the things I really disliked about the initial building import was that
> it overwrote existing data at the same time that new data was brought in.
> These are really two separate import processes and require very different
> considerations.
>
> We can certainly consider using this dataset to improve/update existing
> building geometries, but I think that is a separate process from the import
> we are discussing here. To keep things simple for this import, I would
> suggest removing any building from the import dataset that intersects with
> an existing building in the OSM database. That is, let's not worry about
> conflation for now, and come back and do that work later if we still feel
> there is a strong need for it.
>
> I see the main point of this effort as getting more complete coverage - it
> we want to use the dataset to do quality assurance on existing data, that
> is a whole other discussion.
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
>
> On 2020-01-15 12:55 p.m., Daniel @jfd553 wrote:
>
> Thanks for the quick replies!
>
> Now, about...
>
> *a) Data hosting:*
>
> Thank you James, I really appreciate your offer (and that of others). So
> yes, I think hosting pre-processed data in the task manager, for approved
> regions, is an attractive offer. When we agree on a municipality for
> pre-processing, I will contact you to make the data available.
>
> BTW, I thought ODB data in OSM format was hosted with the OSMCanada task
> manager. I understand that ODB data are currently converted on the fly when
> requested?
>
> *b) Task manager work units for import:*
>
> I agree with Nate, ~ 200 buildings or ~ 1,500 nodes would be suitable. I
> was thinking at the same importation rate, but for an hour of work. It
> seems best to target 20-minute tasks.
>
> *c) Task manager work units for checking already imported data*
>
> According to Nate, it is definitely not faster than actively importing. We
> should then keep the above setup (b).
>
> However, what if I add a new tag to pre-processed data indicating if a
> building was altered or not by the orthogonalization (and simplification)
> process? For instance, *building:altered=no*, would identify buildings
> that were not changed by the process and that could be left unchanged in
> OSM (i.e. 

Re: [Talk-ca] FW: Re: Importing buildings in Canada

[Daniel @jfd553]

Hello Nate,
I understand that you don't like to see an import process that both bring in 
new objects and overwrite existing ones. You also suggest removing "overlapped" 
building from ODB prior to import it. Such pre-processing, that would ensure 
there will be no buildings "overwrite" during the import, is not realistic 
(i.e. you will need to overwrite some buildings anyway). Here are two reasons 
why it would be difficult...

1-  OSM is a dynamic project and, unless you can "clean" the data on the 
fly, you will end up with overlaps since some contributors will have added 
buildings in the meantime.

2-  One cannot assume that an OSM building, and its ODB counterpart, will 
be found at the same location (look at DX and DY columns in ODB inventory 
tables). These are averages, which means there are larger offsets between both 
datasets (i.e. you won't get a match between buildings, or get a match with the 
wrong ones).
The only realistic option is then to manually delete the ODB buildings if they 
overlap OSM ones. Here is what the import guideline suggests [1]...

"If you are importing data where there is already some data in OSM, then you 
need to combine this data in an appropriate way or suppress the import of 
features with overlap with existing data."
Therefore, importing data and using a conflation process is not unusual. Again, 
I understand that in case of an overlap, you go for the last option (suppress 
the import building). I am rather inclined toward using conflation when 
necessary, which means...

-  Importing an ODB building when there is no corresponding one in OSM;

-  Conflating both ODB and OSM buildings when it significantly improves 
existing OSM content;

-  Not importing an ODB building when the corresponding one in OSM is 
adequate.
What do the others on the list think?
Daniel
[1] 
https://wiki.openstreetmap.org/wiki/Import/Guidelines#Don.27t_put_data_on_top_of_data


From: Nate Wessel [mailto:bike...@gmail.com]
Sent: Thursday, January 16, 2020 10:38
To: Daniel @jfd553; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] FW: Re: Importing buildings in Canada


Responding to point C below,
I would strongly suggest that we not confuse the process of importing new data 
with that of updating/modifying existing data in the OSM database. One of the 
things I really disliked about the initial building import was that it 
overwrote existing data at the same time that new data was brought in. These 
are really two separate import processes and require very different 
considerations.

We can certainly consider using this dataset to improve/update existing 
building geometries, but I think that is a separate process from the import we 
are discussing here. To keep things simple for this import, I would suggest 
removing any building from the import dataset that intersects with an existing 
building in the OSM database. That is, let's not worry about conflation for 
now, and come back and do that work later if we still feel there is a strong 
need for it.

I see the main point of this effort as getting more complete coverage - it we 
want to use the dataset to do quality assurance on existing data, that is a 
whole other discussion.

Best,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com
On 2020-01-15 12:55 p.m., Daniel @jfd553 wrote:
Thanks for the quick replies!
Now, about...
a) Data hosting:
Thank you James, I really appreciate your offer (and that of others). So yes, I 
think hosting pre-processed data in the task manager, for approved regions, is 
an attractive offer. When we agree on a municipality for pre-processing, I will 
contact you to make the data available.
BTW, I thought ODB data in OSM format was hosted with the OSMCanada task 
manager. I understand that ODB data are currently converted on the fly when 
requested?
b) Task manager work units for import:
I agree with Nate, ~ 200 buildings or ~ 1,500 nodes would be suitable. I was 
thinking at the same importation rate, but for an hour of work. It seems best 
to target 20-minute tasks.
c) Task manager work units for checking already imported data
According to Nate, it is definitely not faster than actively importing. We 
should then keep the above setup (b).
However, what if I add a new tag to pre-processed data indicating if a building 
was altered or not by the orthogonalization (and simplification) process? For 
instance, building:altered=no, would identify buildings that were not changed 
by the process and that could be left unchanged in OSM (i.e. not imported); 
building:altered=yes for those who were changed by the process and that should 
be imported again. The same pre-processed datasets could then be made available 
for all cases. Thoughts?
d) Finding local mappers:
I agree with Nate's suggestion to try contacting the top 10 mappers in an area. 
Using the "main activity center" would work for most of the contributors but 
selecting other o

Re: [Talk-ca] Importing buildings in Canada

[Daniel @jfd553]

The page "The Open Database of Buildings" has been moved to the "Canada - The 
Open Database of Buildings" not to confuse wiki users from outside the country 
(a Tim Elrick suggestion).

Tim also identified another way to identify local mappers. I added a link to 
his recipe in the above wiki page, in "Get local buy-in before importing" 
section.

Daniel

-Original Message-
From: Tim Elrick [mailto:o...@elrick.de] 
Sent: Wednesday, January 15, 2020 17:19
To: Daniel @jfd553; john whelan
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Importing buildings in Canada

Hi all,

I understand your concerns, John. However, many mappers might not follow 
talk-ca. So, I guess, Daniel's suggestion to contact them, might work 
better than waiting for them to incidentally check talk-ca.

* More to finding local mappers *
By providing the overpass query I just wanted to share a different way 
of contacting active mappers in your area. The advantage of Pascal's 
Who's around me is that you can see the mappers with lots of changesets, 
ie. presumably experienced mappers. The disadvantage is that these 
changesets do not have to be from the area we are interested in 
(however, with activity center in the last 6 months we at least make 
sure they were working in our area); another disadvantage is that you 
cannot collect the names of the mappers easily (or am I missing 
something here?). The advantage of the overpass query is that you get 
that list of names easily and you can see how many objects they have 
added in your area in the past months. The disadvantage, of course, is 
that we don't know how experienced the mappers are (but maybe this 
doesn't matter).

Anyway, either approach works as Daniel already pointed out. Thanks to 
stevea, I now know that I can share Overpass queries easily:
for a geocoded area:
http://overpass-turbo.eu/s/PM9
for a bounding box:
http://overpass-turbo.eu/s/PMb

* Contacting local mappers *
I suggest we design a template letter on the wiki page that can be send 
out to local mappers that include the everything that Daniel suggested 
in his last message below.

Tim


On 2020-01-15 15:54, Daniel @jfd553 wrote:
Hi John, Tim, and the others :-)
John, I understand your concern and if it was not addressed properly, 
this could block the import again.

IMHO, we just need to make sure that we have done everything reasonable 
to inform the concerned contributors, in order to discuss the import in 
case they do not agree with it. That is why I proposed the following, in 
a previous email, concerning local mappers buy-in…

1- We contact them to explain our intentions by referring to the 
appropriate wiki pages.
2- We wait a week or two for them to respond to nothing, have concerns 
or want to help.
3- Without negative answers, we could proceed to the import.

The point 3 above make sure the project is not stalled in case there is 
no or only a few answers. The identification of local contributors using 
Neis’ tool, or the query Tim Elrick just proposed, are what I consider 
reasonable attempts for contacting the local mappers.

Daniel

-Original Message-
From: Tim Elrick via Talk-ca [mailto:talk-ca@openstreetmap.org]
Sent: Wednesday, January 15, 2020 15:12
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Importing buildings in Canada

Hi all,

*a) data hosting*
I can offer to host pre-processed data for the building imports as well.

*b) task manager work units*
I find smaller tasks about 20 minutes each more appealing than 1 hour tasks

*c) checking already existing data*
An added tag would certainly help as you can apply a filter in JOSM then.

*d) finding local mappers*
You can use the following query on http://overpass-turbo.eu/ to get a
list of all users in the time period specified in the area specified.

// overpass query
[out:csv(::user)];
// replace Montreal by any known location in OSM, or see code below
// for bounding box use
{{geocodeArea:Montreal}}->.searchArea;
(
 // I collected users active in the last 6 months, but you can
 // change that
 node(newer:"{{date:6 months}}")(area.searchArea);
 way(newer:"{{date:6 months}}")(area.searchArea);
 relation(newer:"{{date:6 months}}")(area.searchArea);
);
out meta;
// end overpass query

Copy the query into the left side of the window and click Export, then
'raw data directly from Overpass API'. This will generate a csv. You can
then count the number of times a name appears in your list by using
LibreOffice, R, Python or Excel. This will give you the number of
objects a user entered in the last 6 months.

If I do this for Montreal I end up with 106 names who have contributed
20 objects or more in the last half year or 46 names who have
contributed 100 objects and more.

You can then use https://www.openstreetmap.org/message/new/USERNAME by
replacing USERNAME with the names from the list to contact these users.

For areas where there is no geocodeArea in OSM you can use the
boundingbox query below. Firs

Re: [Talk-ca] FW: Re: Importing buildings in Canada

[Nate Wessel]

Responding to point C below,
I would strongly suggest that we not confuse the process of importing 
new data with that of updating/modifying existing data in the OSM 
database. One of the things I really disliked about the initial building 
import was that it overwrote existing data at the same time that new 
data was brought in. These are really two separate import processes and 
require very different considerations.


We can certainly consider using this dataset to improve/update existing 
building geometries, but I think that is a separate process from the 
import we are discussing here. To keep things simple for this import, I 
would suggest removing any building from the import dataset that 
intersects with an existing building in the OSM database. That is, let's 
not worry about conflation for now, and come back and do that work later 
if we still feel there is a strong need for it.


I see the main point of this effort as getting more complete coverage - 
it we want to use the dataset to do quality assurance on existing data, 
that is a whole other discussion.


Best,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com 

On 2020-01-15 12:55 p.m., Daniel @jfd553 wrote:


Thanks for the quick replies!

Now, about...

*a) Data hosting:*

Thank you James, I really appreciate your offer (and that of others). 
So yes, I think hosting pre-processed data in the task manager, for 
approved regions, is an attractive offer. When we agree on a 
municipality for pre-processing, I will contact you to make the data 
available.


BTW, I thought ODB data in OSM format was hosted with the OSMCanada 
task manager. I understand that ODB data are currently converted on 
the fly when requested?


*b) Task manager work units for import:*

I agree with Nate, ~ 200 buildings or ~ 1,500 nodes would be suitable. 
I was thinking at the same importation rate, but for an hour of work. 
It seems best to target 20-minute tasks.


*c) Task manager work units for checking already imported data*

According to Nate, it is definitely not faster than actively 
importing. We should then keep the above setup (b).


However, what if I add a new tag to pre-processed data indicating if a 
building was altered or not by the orthogonalization (and 
simplification) process? For instance, /building:altered=no/, would 
identify buildings that were not changed by the process and that could 
be left unchanged in OSM (i.e. not imported); /building:altered=yes/ 
for those who were changed by the process and that should be imported 
again. The same pre-processed datasets could then be made available 
for all cases. Thoughts?


*d) Finding local mappers:*

I agree with Nate’s suggestion to try contacting the top 10 mappers in 
an area. Using the "main activity center" would work for most of the 
contributors but selecting other overlays (.e.g. an activity center 
over last 6 months) could also work great. As long as we identify who 
might be interested in knowing there is an import coming.


Comments are welcome, particularly about the proposal on c)

Daniel

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