Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-16 Thread Tim Elrick
Thanks for the heads up. As I said, we are not in a rush here, and will 
first transfer the discussion to the Montreal list, then start a page on 
the import wiki and take it from there. On top, the pre-processing will 
be a bit of work as well.


There is lots of data for the City of Montreal that can be imported: 
fire and police stations, free wifi access, traffic lights, swimming 
pools to name but a few. For now, we are talk about including the 
address and building heights into the building import.


I know from reading the Montreal list that someone else is importing bus 
stops at the moment.


Cheers,
Tim

On 2019-02-16 13:07, John Whelan wrote:
If CC-BY 4.0 works great.  I'd go for any addresses etc and any bus
stops you can get hold of as well.

Just be aware that we had a fairly large number of questions asked about
the license etc when we did Ottawa and one of the people questioning
referred the license to the LWG.  Even the basis of CANVEC licensing
came into question at the time.

Many of the questions came from German and other European mappers.

I understand the City of Toronto's Open Data license was referred as
well but that was about two years ago and I note that the LWG web site
has no mention of it so it is probably still in the queue.

Good Luck

Cheerio John

Tim Elrick wrote on 2019-02-16 12:22 PM:

Hi John,

Thanks for pointing me to the license website. The open data of the 
City of Montreal is licensed CC-BY 4.0 and the City has explicitly 
granted OSM the right to use the data on top of that. See: 
http://donnees.ville.montreal.qc.ca/portail/licence/


StatsCan's Open Building Database uses exactly the same data source, 
however, as I pointed out in my last e-mail, it did not split the 
building blocks into actual buildings. The open data of the City of 
Montreal, furthermore, includes building heights which are lost in the 
OBD. These are the reasons why we would like to import the original 
open data.


Cheers,
Tim

On 2019-02-16 11:21, john whelan wrote:
When you look at importing Montreal you might like to look at the
following first.

https://wiki.osmfoundation.org/wiki/OGL_Canada_and_local_variants

Note if the Montreal data in available through Stats Can and the federal
government open data license it might be better to use that data source
from a licensing perspective.

Although data can be given to OpenStreetMap I don't think there in a
foolproof method of recording the fact.  If one person has the paper
record fine but if they are no longer part of the community then there
maybe a problem if the license is challenged.

Cheerio John

On Sun, 10 Feb 2019 at 00:04, Tim Elrick mailto:o...@elrick.de>> wrote:

    Hi all,

    After following the building import discussion for a while now, I
    wanted to chime in as well.

    After moving to Montréal from Germany recently, I got more engaged
    with the local mappers here in MTL (beforehand, I was more analysing
    OSM data scientifically).

    I took part in the initial meeting of the Building Canada 2020
    initiative, in which great interest in the project was expressed by
    many institutions, organizations and businesses. However, apart from
    Statistics Canada, municipalities and OSMappers no one seemed to be
    willing to invest into the effort to support the initiative with
    manpower or funding (to my knowledge). Therefore, I found it quite
    impressive what StatCan has achieved with the Open Building Database
    and do not share the view of some on this list that the initiative
    got off on the wrong foot; but that all water under the bridge now.

    So, yes, there seems to be some interest to use the data from the
    Open Building Database in OSM easily. However, I am also hesitant,
    that one massive import can be the answer.

    I'm generally hesitant with imports as such, maybe because I was
    acculturated in OSM in Germany where OSMappers value original
    entries much more than secondary data. Further, I'm skeptical, that
    secondary data is necessary better than original data (even from
    mapathons). I initiated two mapathons with university students in
    the context of Building Canada 2020. Both mapathons resulted in
    mostly nice buildings, I would say - and, when there is the odd
    not-so-nice building, there is still the validation step as we
    always used the tasking manager [1]. By the way, both mapathons used
    the ID editor; and, of course, you can square buildings in ID as
    well; so, I don't really understand the ID editor bashing that
    appears on this list here now and then. That said, of course, I
    prefer JOSM over ID as it is the more versatile tool, but to
    introduce interested persons to editing in OSM, ID is really nice.

    I'm even more skeptical about imports after Yaro pointed us to the
    Texas import [2]. I wonder why there was no outcry there (or maybe
    there was and I did not hear about it) - the imported data is
    terrible: no 

Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-16 Thread John Whelan
If CC-BY 4.0 works great.  I'd go for any addresses etc and any bus 
stops you can get hold of as well.


Just be aware that we had a fairly large number of questions asked about 
the license etc when we did Ottawa and one of the people questioning 
referred the license to the LWG.  Even the basis of CANVEC licensing 
came into question at the time.


Many of the questions came from German and other European mappers.

I understand the City of Toronto's Open Data license was referred as 
well but that was about two years ago and I note that the LWG web site 
has no mention of it so it is probably still in the queue.


Good Luck

Cheerio John

Tim Elrick wrote on 2019-02-16 12:22 PM:

Hi John,

Thanks for pointing me to the license website. The open data of the 
City of Montreal is licensed CC-BY 4.0 and the City has explicitly 
granted OSM the right to use the data on top of that. See: 
http://donnees.ville.montreal.qc.ca/portail/licence/


StatsCan's Open Building Database uses exactly the same data source, 
however, as I pointed out in my last e-mail, it did not split the 
building blocks into actual buildings. The open data of the City of 
Montreal, furthermore, includes building heights which are lost in the 
OBD. These are the reasons why we would like to import the original 
open data.


Cheers,
Tim

On 2019-02-16 11:21, john whelan wrote:
When you look at importing Montreal you might like to look at the
following first.

https://wiki.osmfoundation.org/wiki/OGL_Canada_and_local_variants

Note if the Montreal data in available through Stats Can and the federal
government open data license it might be better to use that data source
from a licensing perspective.

Although data can be given to OpenStreetMap I don't think there in a
foolproof method of recording the fact.  If one person has the paper
record fine but if they are no longer part of the community then there
maybe a problem if the license is challenged.

Cheerio John

On Sun, 10 Feb 2019 at 00:04, Tim Elrick mailto:o...@elrick.de>> wrote:

    Hi all,

    After following the building import discussion for a while now, I
    wanted to chime in as well.

    After moving to Montréal from Germany recently, I got more engaged
    with the local mappers here in MTL (beforehand, I was more analysing
    OSM data scientifically).

    I took part in the initial meeting of the Building Canada 2020
    initiative, in which great interest in the project was expressed by
    many institutions, organizations and businesses. However, apart from
    Statistics Canada, municipalities and OSMappers no one seemed to be
    willing to invest into the effort to support the initiative with
    manpower or funding (to my knowledge). Therefore, I found it quite
    impressive what StatCan has achieved with the Open Building Database
    and do not share the view of some on this list that the initiative
    got off on the wrong foot; but that all water under the bridge now.

    So, yes, there seems to be some interest to use the data from the
    Open Building Database in OSM easily. However, I am also hesitant,
    that one massive import can be the answer.

    I'm generally hesitant with imports as such, maybe because I was
    acculturated in OSM in Germany where OSMappers value original
    entries much more than secondary data. Further, I'm skeptical, that
    secondary data is necessary better than original data (even from
    mapathons). I initiated two mapathons with university students in
    the context of Building Canada 2020. Both mapathons resulted in
    mostly nice buildings, I would say - and, when there is the odd
    not-so-nice building, there is still the validation step as we
    always used the tasking manager [1]. By the way, both mapathons used
    the ID editor; and, of course, you can square buildings in ID as
    well; so, I don't really understand the ID editor bashing that
    appears on this list here now and then. That said, of course, I
    prefer JOSM over ID as it is the more versatile tool, but to
    introduce interested persons to editing in OSM, ID is really nice.

    I'm even more skeptical about imports after Yaro pointed us to the
    Texas import [2]. I wonder why there was no outcry there (or maybe
    there was and I did not hear about it) - the imported data is
    terrible: no parallel to street buildings, no right angles,
    sometimes even not the right size of building parts. Fact is that
    secondary data buildings footprints can be from many different data
    sources - from AutoCAD, handdrawn by a municipal GIS experts to
    photogrammetric and satellite machine learning sources; all those
    sources have their peculiarities, which I think, you cannot satisfy
    in one import plan fits all - especially, as the Open Building
    Database in Canada is stitched together from those very different
    sources.

    In Montreal, e.g., the source for the Open Building Database is the
    données ouvertes des 

Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-16 Thread Tim Elrick

Hi John,

Thanks for pointing me to the license website. The open data of the City 
of Montreal is licensed CC-BY 4.0 and the City has explicitly granted 
OSM the right to use the data on top of that. See: 
http://donnees.ville.montreal.qc.ca/portail/licence/


StatsCan's Open Building Database uses exactly the same data source, 
however, as I pointed out in my last e-mail, it did not split the 
building blocks into actual buildings. The open data of the City of 
Montreal, furthermore, includes building heights which are lost in the 
OBD. These are the reasons why we would like to import the original open 
data.


Cheers,
Tim

On 2019-02-16 11:21, john whelan wrote:
When you look at importing Montreal you might like to look at the
following first.

https://wiki.osmfoundation.org/wiki/OGL_Canada_and_local_variants

Note if the Montreal data in available through Stats Can and the federal
government open data license it might be better to use that data source
from a licensing perspective.

Although data can be given to OpenStreetMap I don't think there in a
foolproof method of recording the fact.  If one person has the paper
record fine but if they are no longer part of the community then there
maybe a problem if the license is challenged.

Cheerio John

On Sun, 10 Feb 2019 at 00:04, Tim Elrick mailto:o...@elrick.de>> wrote:

Hi all,

After following the building import discussion for a while now, I
wanted to chime in as well.

After moving to Montréal from Germany recently, I got more engaged
with the local mappers here in MTL (beforehand, I was more analysing
OSM data scientifically).

I took part in the initial meeting of the Building Canada 2020
initiative, in which great interest in the project was expressed by
many institutions, organizations and businesses. However, apart from
Statistics Canada, municipalities and OSMappers no one seemed to be
willing to invest into the effort to support the initiative with
manpower or funding (to my knowledge). Therefore, I found it quite
impressive what StatCan has achieved with the Open Building Database
and do not share the view of some on this list that the initiative
got off on the wrong foot; but that all water under the bridge now.

So, yes, there seems to be some interest to use the data from the
Open Building Database in OSM easily. However, I am also hesitant,
that one massive import can be the answer.

I'm generally hesitant with imports as such, maybe because I was
acculturated in OSM in Germany where OSMappers value original
entries much more than secondary data. Further, I'm skeptical, that
secondary data is necessary better than original data (even from
mapathons). I initiated two mapathons with university students in
the context of Building Canada 2020. Both mapathons resulted in
mostly nice buildings, I would say - and, when there is the odd
not-so-nice building, there is still the validation step as we
always used the tasking manager [1]. By the way, both mapathons used
the ID editor; and, of course, you can square buildings in ID as
well; so, I don't really understand the ID editor bashing that
appears on this list here now and then. That said, of course, I
prefer JOSM over ID as it is the more versatile tool, but to
introduce interested persons to editing in OSM, ID is really nice.

I'm even more skeptical about imports after Yaro pointed us to the
Texas import [2]. I wonder why there was no outcry there (or maybe
there was and I did not hear about it) - the imported data is
terrible: no parallel to street buildings, no right angles,
sometimes even not the right size of building parts. Fact is that
secondary data buildings footprints can be from many different data
sources - from AutoCAD, handdrawn by a municipal GIS experts to
photogrammetric and satellite machine learning sources; all those
sources have their peculiarities, which I think, you cannot satisfy
in one import plan fits all - especially, as the Open Building
Database in Canada is stitched together from those very different
sources.

In Montreal, e.g., the source for the Open Building Database is the
données ouvertes des batiments. This is photogrammetric imagery
probably turned into AutoCAD files, which then were exported to a
shapefile and geojson. The building outlines are impressively
precise, however, the open data files contain building blocks not
single buildings [3], however, offer building dividers in a separate
shapefile (I assume due to the export from AutoCAD, see second image
in [3]). Unfortunately, the Open Building Database only included
those building blocks in their data set, making it not very easy to
import into OSM (as they do not include the building dividers).
Hence, a bit of non-trivial pre-processing of the original données
ouvertes des 

Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-16 Thread john whelan
When you look at importing Montreal you might like to look at the following
first.

https://wiki.osmfoundation.org/wiki/OGL_Canada_and_local_variants

Note if the Montreal data in available through Stats Can and the federal
government open data license it might be better to use that data source
from a licensing perspective.

Although data can be given to OpenStreetMap I don't think there in a
foolproof method of recording the fact.  If one person has the paper record
fine but if they are no longer part of the community then there maybe a
problem if the license is challenged.

Cheerio John

On Sun, 10 Feb 2019 at 00:04, Tim Elrick  wrote:

> Hi all,
>
> After following the building import discussion for a while now, I wanted
> to chime in as well.
>
> After moving to Montréal from Germany recently, I got more engaged with
> the local mappers here in MTL (beforehand, I was more analysing OSM data
> scientifically).
>
> I took part in the initial meeting of the Building Canada 2020 initiative,
> in which great interest in the project was expressed by many institutions,
> organizations and businesses. However, apart from Statistics Canada,
> municipalities and OSMappers no one seemed to be willing to invest into the
> effort to support the initiative with manpower or funding (to my
> knowledge). Therefore, I found it quite impressive what StatCan has
> achieved with the Open Building Database and do not share the view of some
> on this list that the initiative got off on the wrong foot; but that all
> water under the bridge now.
>
> So, yes, there seems to be some interest to use the data from the Open
> Building Database in OSM easily. However, I am also hesitant, that one
> massive import can be the answer.
>
> I'm generally hesitant with imports as such, maybe because I was
> acculturated in OSM in Germany where OSMappers value original entries much
> more than secondary data. Further, I'm skeptical, that secondary data is
> necessary better than original data (even from mapathons). I initiated two
> mapathons with university students in the context of Building Canada 2020.
> Both mapathons resulted in mostly nice buildings, I would say - and, when
> there is the odd not-so-nice building, there is still the validation step
> as we always used the tasking manager [1]. By the way, both mapathons used
> the ID editor; and, of course, you can square buildings in ID as well; so,
> I don't really understand the ID editor bashing that appears on this list
> here now and then. That said, of course, I prefer JOSM over ID as it is the
> more versatile tool, but to introduce interested persons to editing in OSM,
> ID is really nice.
>
> I'm even more skeptical about imports after Yaro pointed us to the Texas
> import [2]. I wonder why there was no outcry there (or maybe there was and
> I did not hear about it) - the imported data is terrible: no parallel to
> street buildings, no right angles, sometimes even not the right size of
> building parts. Fact is that secondary data buildings footprints can be
> from many different data sources - from AutoCAD, handdrawn by a municipal
> GIS experts to photogrammetric and satellite machine learning sources; all
> those sources have their peculiarities, which I think, you cannot satisfy
> in one import plan fits all - especially, as the Open Building Database in
> Canada is stitched together from those very different sources.
>
> In Montreal, e.g., the source for the Open Building Database is the
> données ouvertes des batiments. This is photogrammetric imagery probably
> turned into AutoCAD files, which then were exported to a shapefile and
> geojson. The building outlines are impressively precise, however, the open
> data files contain building blocks not single buildings [3], however, offer
> building dividers in a separate shapefile (I assume due to the export from
> AutoCAD, see second image in [3]). Unfortunately, the Open Building
> Database only included those building blocks in their data set, making it
> not very easy to import into OSM (as they do not include the building
> dividers). Hence, a bit of non-trivial pre-processing of the original
> données ouvertes des batiments would be necessary to import them into OSM
> (as the building divider file does also include roof extensions and roof
> shapes). The local OSM group is discussing this pre-processing for a while
> now at their local meetings (we started discussing this even before the
> Building Canada 2020 initiative started). As the City of Montreal has
> granted OSM the explicit use of their open data file, the way forward, we
> think, is to pre-process the original files. Further, there is extensive
> overlap of existing buildings with the open data file. Therefore, the
> imports in Montreal would have to happen in very small batches to not
> destroy the work of other OSMappers.
>
> I am also pretty skeptical about the simplification of the secondary data
> before importing that was suggested on the list 

Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-10 Thread john whelan
Mapping buildings in iD can be done accurately, however going back in time
to the Nepal earthquake generally speaking they were really poor quality.
Pierre first took an interest in data quality around this time.  Well he
was interested before but grew more vocal.  As part of 2020 a number of
mapathons were organised as part of Geoweek using students and iD.  The
results were not pretty and were commented on in talk-ca.  These mapathons
for the most part did not have an experienced OSM mapper to guide them.  I
did one but cheated I took a couple of laptops with JOSM on and we only
used the buildings_tool.  For new mappers they did quite a nice job.  I
have done a fair amount of validation on HOT projects typically I saw 5 -7
buildings per mapper per mapathon done using iD.

Canada is fairly large so many locations do not have a group of OSM
mappers.  Peterborough Ontario, pop 80,000 for example, there is a related
mapathon happening there March 2nd with some students.  However I don't
think there are any local OSM mappers and I can't get there by train or bus
by the time it starts in the morning.

It's these smaller locations that are the problem.  Sorting out the
license, going through the OSM import process and setting up a tile server
takes resources and its these locations are the ones that simply don't have
the experienced mappers available to do the tasks.  The other problem is
students.  France I think thinks all its students should be familiar with
OpenStreetMap so there is interest in the education world.  What we have
found is if the building outlines are present then it is much easier for
students etc to add detail and that is basically what has happened in
Ottawa.

There is a range of points of view about what is acceptable.  The larger
the group, the wider the range and the more difficult it is to get
consensus.  In Ottawa the local mappers are more than happy with the data
quality on the import.

The City of Toronto Open Data licence was submitted for approval by the
local Toronto group must be two years ago now.  So at that time there was a
definite interest by local mappers in using Toronto's open data.

I think I agree with you about running mechanical edits on the data before
importing.  I think Pierre found that using JOSM neither squaring nor the
plugin worked perfectly in all cases.

The way forward probably I suggest an opt out method.  Those locations that
have a local group who would prefer more control we block out.  At the
moment this would include Toronto and Montreal.  That way smaller
municipalities can take advantage of the infrastructure that has been set
up but larger locations with local groups can make their own decisions.

I seem to recall the project plan actually does allow for this.  The
intention certainly was that local groups would sort out the import locally.

Cheerio John







On Sun, 10 Feb 2019 at 00:04, Tim Elrick  wrote:

> Hi all,
>
> After following the building import discussion for a while now, I wanted
> to chime in as well.
>
> After moving to Montréal from Germany recently, I got more engaged with
> the local mappers here in MTL (beforehand, I was more analysing OSM data
> scientifically).
>
> I took part in the initial meeting of the Building Canada 2020 initiative,
> in which great interest in the project was expressed by many institutions,
> organizations and businesses. However, apart from Statistics Canada,
> municipalities and OSMappers no one seemed to be willing to invest into the
> effort to support the initiative with manpower or funding (to my
> knowledge). Therefore, I found it quite impressive what StatCan has
> achieved with the Open Building Database and do not share the view of some
> on this list that the initiative got off on the wrong foot; but that all
> water under the bridge now.
>
> So, yes, there seems to be some interest to use the data from the Open
> Building Database in OSM easily. However, I am also hesitant, that one
> massive import can be the answer.
>
> I'm generally hesitant with imports as such, maybe because I was
> acculturated in OSM in Germany where OSMappers value original entries much
> more than secondary data. Further, I'm skeptical, that secondary data is
> necessary better than original data (even from mapathons). I initiated two
> mapathons with university students in the context of Building Canada 2020.
> Both mapathons resulted in mostly nice buildings, I would say - and, when
> there is the odd not-so-nice building, there is still the validation step
> as we always used the tasking manager [1]. By the way, both mapathons used
> the ID editor; and, of course, you can square buildings in ID as well; so,
> I don't really understand the ID editor bashing that appears on this list
> here now and then. That said, of course, I prefer JOSM over ID as it is the
> more versatile tool, but to introduce interested persons to editing in OSM,
> ID is really nice.
>
> I'm even more skeptical about imports after Yaro 

Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-09 Thread Tim Elrick

Hi all,

After following the building import discussion for a while now, I wanted 
to chime in as well.


After moving to Montréal from Germany recently, I got more engaged with 
the local mappers here in MTL (beforehand, I was more analysing OSM data 
scientifically).


I took part in the initial meeting of the Building Canada 2020 
initiative, in which great interest in the project was expressed by many 
institutions, organizations and businesses. However, apart from 
Statistics Canada, municipalities and OSMappers no one seemed to be 
willing to invest into the effort to support the initiative with 
manpower or funding (to my knowledge). Therefore, I found it quite 
impressive what StatCan has achieved with the Open Building Database and 
do not share the view of some on this list that the initiative got off 
on the wrong foot; but that all water under the bridge now.


So, yes, there seems to be some interest to use the data from the Open 
Building Database in OSM easily. However, I am also hesitant, that one 
massive import can be the answer.


I'm generally hesitant with imports as such, maybe because I was 
acculturated in OSM in Germany where OSMappers value original entries 
much more than secondary data. Further, I'm skeptical, that secondary 
data is necessary better than original data (even from mapathons). I 
initiated two mapathons with university students in the context of 
Building Canada 2020. Both mapathons resulted in mostly nice buildings, 
I would say - and, when there is the odd not-so-nice building, there is 
still the validation step as we always used the tasking manager [1]. By 
the way, both mapathons used the ID editor; and, of course, you can 
square buildings in ID as well; so, I don't really understand the ID 
editor bashing that appears on this list here now and then. That said, 
of course, I prefer JOSM over ID as it is the more versatile tool, but 
to introduce interested persons to editing in OSM, ID is really nice.


I'm even more skeptical about imports after Yaro pointed us to the Texas 
import [2]. I wonder why there was no outcry there (or maybe there was 
and I did not hear about it) - the imported data is terrible: no 
parallel to street buildings, no right angles, sometimes even not the 
right size of building parts. Fact is that secondary data buildings 
footprints can be from many different data sources - from AutoCAD, 
handdrawn by a municipal GIS experts to photogrammetric and satellite 
machine learning sources; all those sources have their peculiarities, 
which I think, you cannot satisfy in one import plan fits all - 
especially, as the Open Building Database in Canada is stitched together 
from those very different sources.


In Montreal, e.g., the source for the Open Building Database is the 
données ouvertes des batiments. This is photogrammetric imagery probably 
turned into AutoCAD files, which then were exported to a shapefile and 
geojson. The building outlines are impressively precise, however, the 
open data files contain building blocks not single buildings [3], 
however, offer building dividers in a separate shapefile (I assume due 
to the export from AutoCAD, see second image in [3]). Unfortunately, the 
Open Building Database only included those building blocks in their data 
set, making it not very easy to import into OSM (as they do not include 
the building dividers). Hence, a bit of non-trivial pre-processing of 
the original données ouvertes des batiments would be necessary to import 
them into OSM (as the building divider file does also include roof 
extensions and roof shapes). The local OSM group is discussing this 
pre-processing for a while now at their local meetings (we started 
discussing this even before the Building Canada 2020 initiative 
started). As the City of Montreal has granted OSM the explicit use of 
their open data file, the way forward, we think, is to pre-process the 
original files. Further, there is extensive overlap of existing 
buildings with the open data file. Therefore, the imports in Montreal 
would have to happen in very small batches to not destroy the work of 
other OSMappers.


I am also pretty skeptical about the simplification of the secondary 
data before importing that was suggested on the list here. As the data 
sources of the Open Building Database are very diverse, one 
simplification method cannot fit all data sources and can lead to 
harming the ground-truth principle. This even happened when Nate tried 
to simplify buildings by hand in Toronto [4], as pointed out by Yaro. 
There might be the odd case, where secondary data has too many nodes in 
a straight line, but, usually, I would assume, that most data sources 
stem from GIS experts or machine learning algorithms; neither would 
include more nodes than necessary for a building outline. And honestly, 
I don't buy the argument of 'too much data clutters our planet dump'. 
Storage space and processing power is no longer an issue, and I would 

Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-05 Thread Pierre Béland via Talk-ca
Danny
Voici un exemple à partir des données d'Ottawa pour tester la fonction de 
correction du Validateur. La requête Overpass ci-dessous permet d'extraire des 
bâtiments jumelés pour les résidences Brookds sur le campus de l'Université 
d'Ottawa.http://overpass-turbo.eu/s/FPT
La correction individuelle de chaque bâtiment à l'aide de la fonction Réparer 
du Validateur JOSM ne corrige que les angles externes et laisse telles quelles 
les nodes partagées avec d'autres bâtiments.   Après correction de tous les 
bâtiments, on constate que les bâtiments ne sont pas orthogonaux là où nodes 
partagées. Et relance lors de la du Validateur, cela n'est pas détecté.
Dans un tel cas, je pense qu'il est mieux de sélectionner un bloc de plusieurs 
bâtiments jumelés et d'utiliser la touche de raccourci «Q» pour orthogonaliser 
l'ensemble. Seul problème, avec le premier bloc de trois bâtiments du haut où 
le bâtiment du centre, le 100 Thomas Moore, a une forme arrondi dans le bas qui 
doit être retracée après l'orthogonalisation. 

Il y a aussi des situations où il semble aussi nécessaire de réviser la forme 
des bâtiments. Voir, par exemple, le 342 Wilbrod street.  La fonction Réparer 
du Validateur JOSM ne donne pas de bons résultats. Après orthogonalisation de 
l'ensemble des trois bâtiments à l'aide de la touche «Q», il est ensuite 
possible selon l'interprétation de l'imagerie de réviser le bâtiment du centre 
à l'aide par exemple de la touche «X».
 
Pierre 
 

Le lundi 4 février 2019 10 h 32 min 17 s HNE, Danny McDonald 
 a écrit :  
 
 In JOSM, open the preferences dialog (F12), go to the data validator tab, and 
click the "show informational level" checkbox (it is third from the top).  Any 
validation done will then check for "Building with an almost square angle", 
which will appear under the Other tab.  "Building with an almost square angle" 
used to cause a Warning, but it was downgraded to Other due to complaints - see 
https://josm.openstreetmap.de/ticket/16280.Danny
On Mon, Feb 4, 2019 at 9:45 AM Yaro Shkvorets  wrote:

Danny,Do you mind sharing how to fix almost square angles in JOSM? I remember 
seeing such warning a year or two ago but for some reason I don't see it 
anymore and can't find it in the Validator settings. Did they remove it from 
the latest version of JOSM or you need to add this rule manually?If there is an 
easy way to do it then we should do it I guess.

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


Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-04 Thread Pierre Béland via Talk-ca
J'ai constaté la même chose a tester CATools. Décevant.

Et merci à Dany, cette fonctionnalité est intéressante.La requête Overpass 
ci-dessous extrait de grands immeubles à Ottawa, certains avec des formes 
rectangulaires, d'autres avec des formes plus complexes, moitié rectangulaire, 
plus divers angles.http://overpass-turbo.eu/s/FNY

Ce qui manque pour corriger de telles géométrie, c'est un outil qui permettrait 
de redresser partiellement, de mettre en parallèle certains cotes, ou redresser 
un angle à 90 degrés, voire 60, 45 a un certain point.  

Pour les demi-cercles, on sélectionne  3 points et outil / Arc de cercle.
 
Pierre 
 

Le lundi 4 février 2019 10 h 50 min 02 s HNE, Yaro Shkvorets 
 a écrit :  
 
 Thanks, it works. Need to run it a few times it looks like. On a random 
Markham block went from 88 warnings down to 4 without ruining geometries, which 
is acceptable IMO. May need to look into its parameters 
(validator.RightAngleBuilding.maximumDelta and 
validator.RightAngleBuilding.minimumDelta) to tweak it for our data.
I've looked into CADTools and BuildingGeneralization plugins but unfortunately 
they don't work properly destroying geometries and rotating polygons.
-- 
Best Regards,
          Yaro Shkvorets  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-04 Thread Yaro Shkvorets
Thanks, it works. Need to run it a few times it looks like. On a random
Markham block went from 88 warnings down to 4 without ruining geometries,
which is acceptable IMO. May need to look into its parameters
(validator.RightAngleBuilding.maximumDelta
and validator.RightAngleBuilding.minimumDelta) to tweak it for our data.

I've looked into CADTools and BuildingGeneralization plugins but
unfortunately they don't work properly destroying geometries and rotating
polygons.

On Mon, Feb 4, 2019 at 10:31 AM Danny McDonald  wrote:

> In JOSM, open the preferences dialog (F12), go to the data validator tab,
> and click the "show informational level" checkbox (it is third from the
> top).  Any validation done will then check for "Building with an almost
> square angle", which will appear under the Other tab.  "Building with an
> almost square angle" used to cause a Warning, but it was downgraded to
> Other due to complaints - see https://josm.openstreetmap.de/ticket/16280.
> Danny
>
> On Mon, Feb 4, 2019 at 9:45 AM Yaro Shkvorets  wrote:
>
>> Danny,
>> Do you mind sharing how to fix almost square angles in JOSM? I remember
>> seeing such warning a year or two ago but for some reason I don't see it
>> anymore and can't find it in the Validator settings.
>> Did they remove it from the latest version of JOSM or you need to add
>> this rule manually?
>> If there is an easy way to do it then we should do it I guess.
>>
>> On Sun, Feb 3, 2019 at 7:51 PM Danny McDonald 
>> wrote:
>>
>>> I largely agree with Yaro, but will say
>>> 1) It is possible to square almost square angles with JOSM - it has an
>>> informational warning in validation, and automatically squares the angle by
>>> slightly moving the offending node.  This fix doesn't ruin the geometry of
>>> the building, as pressing Q so often does.  Unfortunately, it also leads to
>>> other angles in the building not being square.
>>> 3) I'm fine with importing smaller buildings as well (they don't seem to
>>> be in the source data in Toronto, they are for some of the other data
>>> sets).  I believe they were excluded because of their relatively low
>>> importance/permanence.
>>>
>>> I would also like to know how the Toronto building footprints were
>>> produced.  Does anyone know?
>>> DannyMcD
>>>
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>
>>
>> --
>> Best Regards,
>>   Yaro Shkvorets
>>
>

-- 
Best Regards,
  Yaro Shkvorets
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-04 Thread Danny McDonald
In JOSM, open the preferences dialog (F12), go to the data validator tab,
and click the "show informational level" checkbox (it is third from the
top).  Any validation done will then check for "Building with an almost
square angle", which will appear under the Other tab.  "Building with an
almost square angle" used to cause a Warning, but it was downgraded to
Other due to complaints - see https://josm.openstreetmap.de/ticket/16280.
Danny

On Mon, Feb 4, 2019 at 9:45 AM Yaro Shkvorets  wrote:

> Danny,
> Do you mind sharing how to fix almost square angles in JOSM? I remember
> seeing such warning a year or two ago but for some reason I don't see it
> anymore and can't find it in the Validator settings.
> Did they remove it from the latest version of JOSM or you need to add this
> rule manually?
> If there is an easy way to do it then we should do it I guess.
>
> On Sun, Feb 3, 2019 at 7:51 PM Danny McDonald  wrote:
>
>> I largely agree with Yaro, but will say
>> 1) It is possible to square almost square angles with JOSM - it has an
>> informational warning in validation, and automatically squares the angle by
>> slightly moving the offending node.  This fix doesn't ruin the geometry of
>> the building, as pressing Q so often does.  Unfortunately, it also leads to
>> other angles in the building not being square.
>> 3) I'm fine with importing smaller buildings as well (they don't seem to
>> be in the source data in Toronto, they are for some of the other data
>> sets).  I believe they were excluded because of their relatively low
>> importance/permanence.
>>
>> I would also like to know how the Toronto building footprints were
>> produced.  Does anyone know?
>> DannyMcD
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
>
> --
> Best Regards,
>   Yaro Shkvorets
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-04 Thread Pierre Béland via Talk-ca
En faisant une recherche josm + orthogonal, je trouve ce greffon qui semble 
intéressanthttps://wiki.openstreetmap.org/wiki/JOSM/Plugins/CADTools Il 
contient différentes fonctions pour corriger les polygones. Je vois que l'on 
utilise une tolérance 85-95 pour les angles droits. Il est aussi possible de 
modifier les paramètres.


Pierre 
 

Le lundi 4 février 2019 09 h 46 min 17 s HNE, Yaro Shkvorets 
 a écrit :  
 
 Danny,Do you mind sharing how to fix almost square angles in JOSM? I remember 
seeing such warning a year or two ago but for some reason I don't see it 
anymore and can't find it in the Validator settings. Did they remove it from 
the latest version of JOSM or you need to add this rule manually?If there is an 
easy way to do it then we should do it I guess.
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-04 Thread Yaro Shkvorets
Danny,
Do you mind sharing how to fix almost square angles in JOSM? I remember
seeing such warning a year or two ago but for some reason I don't see it
anymore and can't find it in the Validator settings.
Did they remove it from the latest version of JOSM or you need to add this
rule manually?
If there is an easy way to do it then we should do it I guess.

On Sun, Feb 3, 2019 at 7:51 PM Danny McDonald  wrote:

> I largely agree with Yaro, but will say
> 1) It is possible to square almost square angles with JOSM - it has an
> informational warning in validation, and automatically squares the angle by
> slightly moving the offending node.  This fix doesn't ruin the geometry of
> the building, as pressing Q so often does.  Unfortunately, it also leads to
> other angles in the building not being square.
> 3) I'm fine with importing smaller buildings as well (they don't seem to
> be in the source data in Toronto, they are for some of the other data
> sets).  I believe they were excluded because of their relatively low
> importance/permanence.
>
> I would also like to know how the Toronto building footprints were
> produced.  Does anyone know?
> DannyMcD
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>


-- 
Best Regards,
  Yaro Shkvorets
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-03 Thread OSM Volunteer stevea
It is an honor to participate in this good growth.  May good 
(province-at-a-time building) data enter OSM at the hands of skilled OSM 
editors who have good instructions on "how" (the Import Plan can go that 
distance, please finish it) as their skills of good editing OSM data push the 
import ahead.  Speaking for myself, I like what I see here:  a community 
speaking amongst itself/ourselves.

Should "tall enough to ride the ride" volunteers "step right up" I think the 
current red flags can go to yellow, then green.  Nate, Yaro, Pierre, Blake, 
Nate, John, Danny, so many others here unnamed have shown leadership.  Many 
Canadians seem on the road to "how" and "talk amongst yourselves."  Good is not 
the enemy.  Good are good enough as they are included with "how."  Thumbs up 
from here ahead.  I keep trying to be outta here.

Et, voilá.

SteveA
> 


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


Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-03 Thread Danny McDonald
I largely agree with Yaro, but will say
1) It is possible to square almost square angles with JOSM - it has an
informational warning in validation, and automatically squares the angle by
slightly moving the offending node.  This fix doesn't ruin the geometry of
the building, as pressing Q so often does.  Unfortunately, it also leads to
other angles in the building not being square.
3) I'm fine with importing smaller buildings as well (they don't seem to be
in the source data in Toronto, they are for some of the other data sets).
I believe they were excluded because of their relatively low
importance/permanence.

I would also like to know how the Toronto building footprints were
produced.  Does anyone know?
DannyMcD
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-03 Thread Yaro Shkvorets
Having reviewed the changeset, here are my 2 cents. OsmCha link for
reference: https://osmcha.mapbox.com/changesets/66881357/

1) IMO squaring is not needed in most of those cases.
- You can see difference between square and non-square ONLY at high zoom
level. And even then, it's not visible to the naked eye. We are talking
about inches here.
- Sometimes squaring is plain wrong to be applied here. Even though you
paid very close attention you managed to square a couple of non-square
buildings. Like this facade is not supposed to be square for example:
https://i.imgur.com/H10360K.png I might be OK with squaring almost-square
angles if there is a simple plugin for that. The way you propose to do it,
by going building-by-building and pressing Q is completely unsustainable
and sometimes makes things bad.
- Another thing, this particular neighbourhood is pretty dense and mature
and therefore has mostly square buildings. I can only imagine how bad it
would become if you ask people to square things in newer developments where
buildings often come in irregular shapes.
- Like mentioned above, many successful import didn't require squaring. In
this Texas one, 100% of buildings are not perfectly square:
https://www.openstreetmap.org/#map=19/32.97102/-96.78231


2) Simplification is good to have, sure. Obviously standard Shift-Y in JOSM
is a no-starter. If we can find a good way to simplify ways without losing
original geometry and causing overlapping issues we should do it. But even
then, reducing 500MB province extract to 499MB should not be a hill to die
on.

3) Manually mapping all the sheds and garages is completely unsustainable.
Having seen over the last couple of years how much real interest there is
in doing actual work importing buildings in Canada (almost zero) adding
this requirement will undoubtedly kill the project. Sure you will
meticulously map your own neighbourhood, but who will map thousands of
other places with the same attention to details? Also, you did rather poor
job at classifying buildings you add, tagging them all with building=yes.
Properly classifying secondary buildings like sheds and garages in a
project like this is pretty important IMO. I agree with John, we should
leave sheds to local mappers to trace manually.

To sum up, yes we can do better. But this is the perfect example when
"better" is the enemy of "good".

On Sun, Feb 3, 2019 at 12:34 PM Nate Wessel  wrote:

> Hi all,
>
> I had a chance this morning to work on cleaning up some of the
> already-imported data in Toronto. I wanted to be a little methodical about
> this, so I picked a single typical block near where I live. All the
> building data on this block came from the import and I did everything in
> one changeset: https://www.openstreetmap.org/changeset/66881357
>
> What I found was that:
>
> 1) Every single building needed squaring
>
> 2) Most buildings needed at least some simplification.
>
> 3) 42 buildings were missing.
>
> I knew going in that the first two would be an issue, but what really
> surprised me was just how many sheds had not been imported. There are only
> 53 houses on the block, but 42 sheds/garages/outbuildings, some of them
> quite large, and none of which had been mapped.
>
> I haven't seen the quality of the outbuildings in the source data, and
> maybe I would change my mind if I did, but I think if we're going to do
> this import properly, we're going to have to bring in the other half of the
> data. I had seen in the original import instructions that small buildings
> were being excluded - was there a reason for this?
>
> I also want to say: given how long it took me to clean up and properly
> remap this one block, I'll say again that the size of the import tasks is
> way, way, way too large. There is absolutely no way that someone could have
> carefully looked at and verified this data as it was going in. I just spent
> a half hour fixing up probably about one-hundredth of a task square.
>
> We can do better than this!
> --
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>


-- 
Best Regards,
  Yaro Shkvorets
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-03 Thread OSM Volunteer stevea
Mmm, careful with your language, John.  The data "have a license which is 
compatible with OSM's ODbL" (is an accurate way to say it).  I believe that 
took about eight years and was a difficult slog, a lot of hard work by many, 
lessons learned from Ottawa, a determination by OSM's LWG, but it is done.  (I 
am grateful for that, it is an important milestone).

A different issue is whether the data and their concomitant quality "are 
acceptable" to the OSM community.  The license being ODbL compatible is not 
that; these are different issues.  We now discuss data quality (and what to do 
to improve them, if anything) here in talk-ca and in the mildly-being-updated 
Import Plan, with experiences of what Yaro, Danny and Nate have done in Toronto.

It is not the case, as John says, that "the data (are) licensed to be 
acceptable to (OSM)."  The concept of "acceptability" is not related to the 
data being licensed compatible with ODbL.

What often/usually happens is an Import Plan gets wide vetting and acceptance 
by the OSM community before data become imported, including 
suitability/acceptability of the quality of the data.  What happened here is 
the Import Plan was attempted to be widely vetted, but this seems to have been 
largely ignored or little-paid-attention-to.  While the Plan's initial 
shortcomings were pointed out, yet not remedied, the Import began, then the 
community began to react (with some complaint and some "what Yaro does seems 
OK").  Yaro (and Nate, I believe) then updated the Import Plan with Yaro's 
specific technical steps.

Still, complaints and/or disagreements about simplification, squaring and 
potentially other issues continue.  (As two asides, I'll say that MANY 
buildings are not necessarily "square" — like buildings with bay windows — and 
that truly square/rectangular buildings should express this with a tagged 
way/closed polygon made up of exactly four nodes).

As these discussions continue, eventually what will emerge is "how do we 
(algorithmically, manually...) change the data, whether pre-import or 
during-import, so that they achieve wide acceptance as to their quality by the 
community."  We're getting closer, it seems to me, but I don't think we're 
there yet.

Nobody seems to be arguing there is or isn't a "desire to bring in the 
buildings by many" or to "use them for many purposes."  That point seems 
"decided."  The questions remain:  "how, with the existing data?"  Once those 
are determined (and documented in the Import Plan), over time, the data will 
(or will not) be imported.  I wish to offer encouragement to this process, it 
does appear to continue here and can likely bear fruit in the near future.  
Keep going!  Consensus is ahead!

SteveA

On Feb 3, 2019, at 10:55 AM, john whelan  wrote:
> So I suggest that you name yourself as the coordinator on the wiki page for 
> Toronto that allows the local mappers in Toronto to import at the rate and to 
> the standard you suggest.
> 
> For the rest of the country the data is licensed to be acceptable to 
> OpenStreetMap thus anyone can set up their own import plan and import it even 
> if this import is abandoned.  I'd like to see this voiced as the general 
> desire though on talk-ca before it happens as it was a talk-ca decision to 
> proceed.
> 
> My reading of the posts on talk-ca is that there is a desire to bring in the 
> buildings by many.  There is also a desire by many to use them for many 
> purposes.
> 
> Cheerio John
> 
> On Sun, Feb 3, 2019, 1:42 PM Nate Wessel  John, 
> You seem to be mostly addressing topics which have been brought up elsewhere. 
> My email was meant to address specific data quality issues in Toronto, so I'm 
> not sure how to respond to all of this. 
> To your broader question though, my position is that we *do* have the 
> volunteers and skills necessary to make this a good import. Supposing that we 
> didn't though, then I would have to say that the import should wait until we 
> have the right people working on it. A bad import is worse than no import.
> 
> Cheers,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 

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


Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-03 Thread john whelan
So I suggest that you name yourself as the coordinator on the wiki page for
Toronto that allows the local mappers in Toronto to import at the rate and
to the standard you suggest.

For the rest of the country the data is licensed to be acceptable to
OpenStreetMap thus anyone can set up their own import plan and import it
even if this import is abandoned.  I'd like to see this voiced as the
general desire though on talk-ca before it happens as it was a talk-ca
decision to proceed.

My reading of the posts on talk-ca is that there is a desire to bring in
the buildings by many.  There is also a desire by many to use them for many
purposes.

Cheerio John

On Sun, Feb 3, 2019, 1:42 PM Nate Wessel  John,
>
> You seem to be mostly addressing topics which have been brought up
> elsewhere. My email was meant to address specific data quality issues in
> Toronto, so I'm not sure how to respond to all of this.
>
> To your broader question though, my position is that we *do* have the
> volunteers and skills necessary to make this a good import. Supposing that
> we didn't though, then I would have to say that the import should wait
> until we have the right people working on it. A bad import is worse than no
> import.
>
> Cheers,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 2/3/19 1:14 PM, john whelan wrote:
>
> My expectation was that the import would be based on the city's records of
> foundations for the buildings.
>
> I would not expect to see sheds etc.and I'd be quite happy to only get
> most of the buildings. The rest can be added by local mappers at a later
> date.
>
> My expectation is they will be consistent and not some mapped from Bing,
> others from ESRI etc.
>
> There are estimated to be in excess of 11,000,000 buildings in Canada.  I
> don't think we have enough skilled mappers to map them all from imagery.
>
> My expectation is the import would give us a reasonable number of fairly
> accurate building outlines at relatively low cost in mapper time.  Missing
> building imports from city open data are now fairly common in many parts of
> the world.
>
> My expectation is that the building outlines would have additional tags
> added and that this would draw in less skilled mappers.  At the same time
> corrections could be made to the outlines if deemed necessary.
>
> It would avoid too many badly mapped buildings.
>
> Before the import started it was raised in talk-ca and there was some
> discussion.  I understand you were not a member at that time or took part
> in that discussion but that doesn't change the fact that the issue was
> discussed.
>
> The idea of a single import plan came from talk-ca and that is why there
> is a single import plan covering the entire country and there was
> discussion on talk-ca on the point.
>
> The original plan on the wiki mentioned having some coordination in an
> area.  I don't think this happened but it was an attempt to give a louder
> local voice as it was recognised it would be better if local mappers took
> the lead.
>
> Different mappers have different ideas of what is acceptable.  I think
> your standards are fairly high thus more demanding in resources and do we
> have enough resources?  I don't think we do to import to the standard at
> which you are asking.
>
> Could you clarify what you are saying?
>
> I assume that for other parts of the country if they wish to continue and
> find the building outlines acceptable they may do so?
>
> Thanks John
>
> Thanks John
>
>
>
> On Sun, 3 Feb 2019 at 12:34, Nate Wessel  wrote:
>
>> Hi all,
>>
>> I had a chance this morning to work on cleaning up some of the
>> already-imported data in Toronto. I wanted to be a little methodical about
>> this, so I picked a single typical block near where I live. All the
>> building data on this block came from the import and I did everything in
>> one changeset: https://www.openstreetmap.org/changeset/66881357
>>
>> What I found was that:
>>
>> 1) Every single building needed squaring
>>
>> 2) Most buildings needed at least some simplification.
>>
>> 3) 42 buildings were missing.
>>
>> I knew going in that the first two would be an issue, but what really
>> surprised me was just how many sheds had not been imported. There are only
>> 53 houses on the block, but 42 sheds/garages/outbuildings, some of them
>> quite large, and none of which had been mapped.
>>
>> I haven't seen the quality of the outbuildings in the source data, and
>> maybe I would change my mind if I did, but I think if we're going to do
>> this import properly, we're going to have to bring in the other half of the
>> data. I had seen in the original import instructions that small buildings
>> were being excluded - was there a reason for this?
>>
>> I also want to say: given how long it took me to clean up and properly
>> remap this one block, I'll say again that the size of the import tasks is
>> way, way, way too large. There 

Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-03 Thread Nate Wessel

John,

You seem to be mostly addressing topics which have been brought up 
elsewhere. My email was meant to address specific data quality issues in 
Toronto, so I'm not sure how to respond to all of this.


To your broader question though, my position is that we *do* have the 
volunteers and skills necessary to make this a good import. Supposing 
that we didn't though, then I would have to say that the import should 
wait until we have the right people working on it. A bad import is worse 
than no import.


Cheers,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 2/3/19 1:14 PM, john whelan wrote:
My expectation was that the import would be based on the city's 
records of foundations for the buildings.


I would not expect to see sheds etc.and I'd be quite happy to only get 
most of the buildings. The rest can be added by local mappers at a 
later date.


My expectation is they will be consistent and not some mapped from 
Bing, others from ESRI etc.


There are estimated to be in excess of 11,000,000 buildings in 
Canada.  I don't think we have enough skilled mappers to map them all 
from imagery.


My expectation is the import would give us a reasonable number of 
fairly accurate building outlines at relatively low cost in mapper 
time.  Missing building imports from city open data are now fairly 
common in many parts of the world.


My expectation is that the building outlines would have additional 
tags added and that this would draw in less skilled mappers.  At the 
same time corrections could be made to the outlines if deemed necessary.


It would avoid too many badly mapped buildings.

Before the import started it was raised in talk-ca and there was some 
discussion.  I understand you were not a member at that time or took 
part in that discussion but that doesn't change the fact that the 
issue was discussed.


The idea of a single import plan came from talk-ca and that is why 
there is a single import plan covering the entire country and there 
was discussion on talk-ca on the point.


The original plan on the wiki mentioned having some coordination in an 
area.  I don't think this happened but it was an attempt to give a 
louder local voice as it was recognised it would be better if local 
mappers took the lead.


Different mappers have different ideas of what is acceptable.  I think 
your standards are fairly high thus more demanding in resources and do 
we have enough resources?  I don't think we do to import to the 
standard at which you are asking.


Could you clarify what you are saying?

I assume that for other parts of the country if they wish to continue 
and find the building outlines acceptable they may do so?


Thanks John

Thanks John



On Sun, 3 Feb 2019 at 12:34, Nate Wessel > wrote:


Hi all,

I had a chance this morning to work on cleaning up some of the
already-imported data in Toronto. I wanted to be a little
methodical about this, so I picked a single typical block near
where I live. All the building data on this block came from the
import and I did everything in one changeset:
https://www.openstreetmap.org/changeset/66881357

What I found was that:

1) Every single building needed squaring

2) Most buildings needed at least some simplification.

3) 42 buildings were missing.

I knew going in that the first two would be an issue, but what
really surprised me was just how many sheds had not been imported.
There are only 53 houses on the block, but 42
sheds/garages/outbuildings, some of them quite large, and none of
which had been mapped.

I haven't seen the quality of the outbuildings in the source data,
and maybe I would change my mind if I did, but I think if we're
going to do this import properly, we're going to have to bring in
the other half of the data. I had seen in the original import
instructions that small buildings were being excluded - was there
a reason for this?

I also want to say: given how long it took me to clean up and
properly remap this one block, I'll say again that the size of the
import tasks is way, way, way too large. There is absolutely no
way that someone could have carefully looked at and verified this
data as it was going in. I just spent a half hour fixing up
probably about one-hundredth of a task square.

We can do better than this!

-- 
Nate Wessel

Jack of all trades, Master of Geography, PhD candidate in Urban
Planning
NateWessel.com 

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

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


Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-03 Thread john whelan
My expectation was that the import would be based on the city's records of
foundations for the buildings.

I would not expect to see sheds etc.and I'd be quite happy to only get most
of the buildings. The rest can be added by local mappers at a later date.

My expectation is they will be consistent and not some mapped from Bing,
others from ESRI etc.

There are estimated to be in excess of 11,000,000 buildings in Canada.  I
don't think we have enough skilled mappers to map them all from imagery.

My expectation is the import would give us a reasonable number of fairly
accurate building outlines at relatively low cost in mapper time.  Missing
building imports from city open data are now fairly common in many parts of
the world.

My expectation is that the building outlines would have additional tags
added and that this would draw in less skilled mappers.  At the same time
corrections could be made to the outlines if deemed necessary.

It would avoid too many badly mapped buildings.

Before the import started it was raised in talk-ca and there was some
discussion.  I understand you were not a member at that time or took part
in that discussion but that doesn't change the fact that the issue was
discussed.

The idea of a single import plan came from talk-ca and that is why there is
a single import plan covering the entire country and there was discussion
on talk-ca on the point.

The original plan on the wiki mentioned having some coordination in an
area.  I don't think this happened but it was an attempt to give a louder
local voice as it was recognised it would be better if local mappers took
the lead.

Different mappers have different ideas of what is acceptable.  I think your
standards are fairly high thus more demanding in resources and do we have
enough resources?  I don't think we do to import to the standard at which
you are asking.

Could you clarify what you are saying?

I assume that for other parts of the country if they wish to continue and
find the building outlines acceptable they may do so?

Thanks John

Thanks John



On Sun, 3 Feb 2019 at 12:34, Nate Wessel  wrote:

> Hi all,
>
> I had a chance this morning to work on cleaning up some of the
> already-imported data in Toronto. I wanted to be a little methodical about
> this, so I picked a single typical block near where I live. All the
> building data on this block came from the import and I did everything in
> one changeset: https://www.openstreetmap.org/changeset/66881357
>
> What I found was that:
>
> 1) Every single building needed squaring
>
> 2) Most buildings needed at least some simplification.
>
> 3) 42 buildings were missing.
>
> I knew going in that the first two would be an issue, but what really
> surprised me was just how many sheds had not been imported. There are only
> 53 houses on the block, but 42 sheds/garages/outbuildings, some of them
> quite large, and none of which had been mapped.
>
> I haven't seen the quality of the outbuildings in the source data, and
> maybe I would change my mind if I did, but I think if we're going to do
> this import properly, we're going to have to bring in the other half of the
> data. I had seen in the original import instructions that small buildings
> were being excluded - was there a reason for this?
>
> I also want to say: given how long it took me to clean up and properly
> remap this one block, I'll say again that the size of the import tasks is
> way, way, way too large. There is absolutely no way that someone could have
> carefully looked at and verified this data as it was going in. I just spent
> a half hour fixing up probably about one-hundredth of a task square.
>
> We can do better than this!
> --
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca