Re: [Talk-ca] Radio-Canada - Carte Google premières nations est la meilleure - Réagissez

[Pierre Béland]

Variables pour identifier les communautés autochtones du Canada
Pour montrer l'utilité d'ajouter des variables de communautés, j'ai ajouté les 
variables indigenous pour les Inuits, les Cris et les Innus du Québec. Si on 
s'entend sur une classification à utiliser, il sera ensuite facile de modifier 
ces variables.
  
|   |

 
La requête Overpass ci-dessous extrait les nodes place ayant une variable qui 
contient indigenous.http://overpass-turbo.eu/s/q4Q

À partir de telles variables, il est facile de produire des cartes thématiques 
sur les communautés autochtones du Canada. Il serait par exemple facile de 
produire une carte uMap présentant les Premières nations et les communatés 
Inuit.  Pierre 





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

Re: [Talk-ca] Radio-Canada - Carte Google premières nations est la meilleure - Réagissez

[Pierre Béland]

Merci James et John

Les données open.canada.ca nous permettent de vérifier et ajouter si nécessaire 
les noms de chaque village / communauté. Je vais proposer plus bas des noms de 
variables pour permettre de faire des requêtes pour extraire les données sur 
ces communautés autochtones.

Puis oui, il serait bien de pouvoir associer des  organisations représentant 
les Premières nations, les Inuits et les Métis.

Les pages Wikipedia sont aussi utiles pour mieux connaitre ces communautés.
en
https://en.wikipedia.org/wiki/First_Nations
https://en.wikipedia.org/wiki/Inuit
https://en.wikipedia.org/wiki/M%C3%A9tis_in_Canada
fr
https://fr.wikipedia.org/wiki/Premi%C3%A8res_Nations
https://fr.wikipedia.org/wiki/Inuits
https://fr.wikipedia.org/wiki/M%C3%A9tis_(Canada)


Liste des communautés classées par nation / lien vers pages individuelles par 
communautéDisponibles en français - Je n'ai pas trouvé l'équivalent en anglais 
- Cela permet ausi d'ajouter un lien wikipedia vers la page d'une communauté 
locale
https://fr.wikipedia.org/wiki/Liste_des_Premi%C3%A8res_Nations_du_Canada
https://fr.wikipedia.org/wiki/Liste_des_communaut%C3%A9s_inuites_du_Canada
metis ??

Variables pour identifier les communautés autochtones du Canada
Je propose d'ajouter 3 variables  qui indiquent le nom de communauté et la 
nation. Mais, il n'est pas facile de trouver un nom de variable qui représente 
toutes ces communautés, tout en évitant d'être péjoratif. Voici une première 
proposition.

indigenous_group (les 3 grands groupes)   Innu, Première nation (First Nation), 
Metis
 indigenous_nation  (Nation) Exemple: Anishinaabe, Oneida, Mohawk, Cri / Cree,  
Innu, Inuit, etc. 
indigenous_community  (communauté locale, bande indienne)  Exemple : Chapleau 
Ojibway, Uashat, Quaqtaq 
  
Pierre 

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

Re: [Talk-ca] Radio-Canada - Carte Google premières nations est la meilleure - Réagissez

[john whelan]

The Northwest Territories has 11 official languages by the way.

Cheerio John

2017-06-29 14:49 GMT-04:00 john whelan :

> Have we any contacts at INAC?  This strikes me as being something the
> locals are best equipped to handle especially if we point out we can handle
> the native script for names.
>
> I think INAC are best placed to coordinate this or possibly gov.nt.ca.
>
> Cheerio John
>
> 2017-06-29 14:30 GMT-04:00 James :
>
>> Au cas que le monde ont besoin des endroids ou se trouve les premieres
>> nations le Canada a ses donnees:
>>
>> First Nations Location dataset: http://open.canada.ca/data/en/
>> dataset/b6567c5c-8339-4055-99fa-63f92114d9e4
>> Inuit Communities Location dataset: http://open.canada.ca/data/en/
>> dataset/2bcf34b5-4e9a-431b-9e43-1eace6c873bd
>>
>> Bing est souvant le meilleur pour ajouter des details, mais Digital globe
>> est un bon candiat en ce moment. J'ai deja fait beaucoup de travail dans
>> les villages des premieres nations, comme ajouter les routes et les
>> edifices ex: http://pierzen.dev.openstreetmap.org/hot/leaflet/OSM-
>> Compare-google.html#15/52.2135/-81.6861  Je vais plus me concentrer sur
>> ceci maintenant que les bordures administratives
>>
>> In case people were wondering where the first nations villages are
>> located(see above links). Often Bing is the best to add details, but
>> Digital globe is a good cadidate as well. I've been doing a lot of first
>> nation's villages recently like adding buildings/missing roads ex:
>> http://pierzen.dev.openstreetmap.org/hot/leaflet/OSM-
>> Compare-google.html#15/52.2135/-81.6861 I'm going to concentrate on this
>> now instead of administrative borders
>>
>> 2017-06-25 9:40 GMT-04:00 Pierre Béland :
>>
>>> Google a réussi encore aujourd'hui un coup de pub sur Radio-Canada en
>>> indiquant avoir ajouté des milliers de villages autochtones sur la carte du
>>> Canada. On invite les autochtones a collaborer et cartographier. Texte en
>>> français https://t.co/b0K6k75krw
>>>
>>> C'est aussi une occasion pour la communauté OSM de faire un coup de pub
>>> en réagissant et montrant la supériorité de la carte OpenStreetMap.
>>> Assurez-vous de bien cartographier les villages autochtones. Puis je vous
>>> invite à réagir aux tweets que je viens de publier.
>>>
>>> Vous pouvez utiliser la fonction Reply et réagir de différentes façons.
>>> - Parler des outils Android / iOS gratuit
>>> - Ajouter un lien vers la carte osm-compare-google y comparant un
>>> village autochtone plus détaillé sur OSM
>>>
>>> carte osm-compare-google
>>> http://pierzen.dev.openstreetmap.org/hot/leaflet/OSM-Compare
>>> -google.html#15/61.5986/-71.9520
>>> Tweet français
>>> https://twitter.com/pierzen/status/878968053995905025
>>>
>>>
>>> Tweet Anglais
>>> https://twitter.com/pierzen/status/878968496226525185
>>>
>>>
>>>
>>> Pierre
>>>
>>> ___
>>> 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
>>
>>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Radio-Canada - Carte Google premières nations est la meilleure - Réagissez

[john whelan]

Have we any contacts at INAC?  This strikes me as being something the
locals are best equipped to handle especially if we point out we can handle
the native script for names.

I think INAC are best placed to coordinate this or possibly gov.nt.ca.

Cheerio John

2017-06-29 14:30 GMT-04:00 James :

> Au cas que le monde ont besoin des endroids ou se trouve les premieres
> nations le Canada a ses donnees:
>
> First Nations Location dataset: http://open.canada.ca/data/en/
> dataset/b6567c5c-8339-4055-99fa-63f92114d9e4
> Inuit Communities Location dataset: http://open.canada.ca/data/en/
> dataset/2bcf34b5-4e9a-431b-9e43-1eace6c873bd
>
> Bing est souvant le meilleur pour ajouter des details, mais Digital globe
> est un bon candiat en ce moment. J'ai deja fait beaucoup de travail dans
> les villages des premieres nations, comme ajouter les routes et les
> edifices ex: http://pierzen.dev.openstreetmap.org/hot/leaflet/
> OSM-Compare-google.html#15/52.2135/-81.6861  Je vais plus me concentrer
> sur ceci maintenant que les bordures administratives
>
> In case people were wondering where the first nations villages are
> located(see above links). Often Bing is the best to add details, but
> Digital globe is a good cadidate as well. I've been doing a lot of first
> nation's villages recently like adding buildings/missing roads ex:
> http://pierzen.dev.openstreetmap.org/hot/leaflet/
> OSM-Compare-google.html#15/52.2135/-81.6861 I'm going to concentrate on
> this now instead of administrative borders
>
> 2017-06-25 9:40 GMT-04:00 Pierre Béland :
>
>> Google a réussi encore aujourd'hui un coup de pub sur Radio-Canada en
>> indiquant avoir ajouté des milliers de villages autochtones sur la carte du
>> Canada. On invite les autochtones a collaborer et cartographier. Texte en
>> français https://t.co/b0K6k75krw
>>
>> C'est aussi une occasion pour la communauté OSM de faire un coup de pub
>> en réagissant et montrant la supériorité de la carte OpenStreetMap.
>> Assurez-vous de bien cartographier les villages autochtones. Puis je vous
>> invite à réagir aux tweets que je viens de publier.
>>
>> Vous pouvez utiliser la fonction Reply et réagir de différentes façons.
>> - Parler des outils Android / iOS gratuit
>> - Ajouter un lien vers la carte osm-compare-google y comparant un village
>> autochtone plus détaillé sur OSM
>>
>> carte osm-compare-google
>> http://pierzen.dev.openstreetmap.org/hot/leaflet/OSM-
>> Compare-google.html#15/61.5986/-71.9520
>> Tweet français
>> https://twitter.com/pierzen/status/878968053995905025
>>
>>
>> Tweet Anglais
>> https://twitter.com/pierzen/status/878968496226525185
>>
>>
>>
>> Pierre
>>
>> ___
>> 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
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Radio-Canada - Carte Google premières nations est la meilleure - Réagissez

[James]

Au cas que le monde ont besoin des endroids ou se trouve les premieres
nations le Canada a ses donnees:

First Nations Location dataset:
http://open.canada.ca/data/en/dataset/b6567c5c-8339-4055-99fa-63f92114d9e4
Inuit Communities Location dataset:
http://open.canada.ca/data/en/dataset/2bcf34b5-4e9a-431b-9e43-1eace6c873bd

Bing est souvant le meilleur pour ajouter des details, mais Digital globe
est un bon candiat en ce moment. J'ai deja fait beaucoup de travail dans
les villages des premieres nations, comme ajouter les routes et les
edifices ex:
http://pierzen.dev.openstreetmap.org/hot/leaflet/OSM-Compare-google.html#15/52.2135/-81.6861
Je vais plus me concentrer sur ceci maintenant que les bordures
administratives

In case people were wondering where the first nations villages are
located(see above links). Often Bing is the best to add details, but
Digital globe is a good cadidate as well. I've been doing a lot of first
nation's villages recently like adding buildings/missing roads ex:
http://pierzen.dev.openstreetmap.org/hot/leaflet/OSM-Compare-google.html#15/52.2135/-81.6861
I'm going to concentrate on this now instead of administrative borders

2017-06-25 9:40 GMT-04:00 Pierre Béland :

> Google a réussi encore aujourd'hui un coup de pub sur Radio-Canada en
> indiquant avoir ajouté des milliers de villages autochtones sur la carte du
> Canada. On invite les autochtones a collaborer et cartographier. Texte en
> français https://t.co/b0K6k75krw
>
> C'est aussi une occasion pour la communauté OSM de faire un coup de pub en
> réagissant et montrant la supériorité de la carte OpenStreetMap.
> Assurez-vous de bien cartographier les villages autochtones. Puis je vous
> invite à réagir aux tweets que je viens de publier.
>
> Vous pouvez utiliser la fonction Reply et réagir de différentes façons.
> - Parler des outils Android / iOS gratuit
> - Ajouter un lien vers la carte osm-compare-google y comparant un village
> autochtone plus détaillé sur OSM
>
> carte osm-compare-google
> http://pierzen.dev.openstreetmap.org/hot/leaflet/
> OSM-Compare-google.html#15/61.5986/-71.9520
> Tweet français
> https://twitter.com/pierzen/status/878968053995905025
>
>
> Tweet Anglais
> https://twitter.com/pierzen/status/878968496226525185
>
>
>
> Pierre
>
> ___
> 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

[Talk-ca] weeklyOSM #362 2017-06-20-2017-06-26

[weeklyteam]

The weekly round-up of OSM news, issue # 362,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9199/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] [Imports] Ottawa, Canada Tree Import

[James]

I can already see the Rideau Mall roof top as being an exception (there's a
giant garden on the roof)

On Thu, Jun 29, 2017 at 8:52 AM, Denis Carriere 
wrote:

> There's many of us that are from the local Ottawa area, we will make sure
> we capture those exceptions. I am sure in the Downtown area we will find
> some valid trees that are completely within the building (green spaces on
> top of a roof).
>
> *~~*
> *Denis Carriere*
> *GIS Software & Systems Specialist*
>
> On Thu, Jun 29, 2017 at 8:34 AM, Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
>
>>
>>
>> sent from a phone
>>
>> > On 29. Jun 2017, at 14:01, Rory McCann  wrote:
>> >
>> > When doing an import, it's important that someone does this sort of
>> > work. That's part of the process of doing an import, to learn more about
>> > the accuracy of the data you have, and to check how it would look after
>> > you import it. You shouldn't just presume everything will fit together
>> > 100%, someone needs to do this sort of analysis.
>>
>>
>> yes, it will give you some indication about obvious or very likely
>> errors, still there are also trees inside buildings, it is a rare
>> situation, but I could recall several instances where I've seen it (both,
>> buildings built around trees/leaving gaps/holes, and trees being planted
>> inside buildings).
>>
>> Problems like these are obvious, but there's no indication that the rest
>> of the trees are more correct, it might be just harder to spot the issues
>> when the data seems fine on first glance.
>>
>> Are you local to the area? I'd look for some trees you know that fell in
>> the past years and see whether these events are reflected.
>>
>> Cheers,
>> Martin
>>
>>
>>
>> ___
>> Imports mailing list
>> impo...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
>>
>
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
>


-- 
外に遊びに行こう！
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] [Imports] Ottawa, Canada Tree Import

[Denis Carriere]

There's many of us that are from the local Ottawa area, we will make sure
we capture those exceptions. I am sure in the Downtown area we will find
some valid trees that are completely within the building (green spaces on
top of a roof).

*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

On Thu, Jun 29, 2017 at 8:34 AM, Martin Koppenhoefer  wrote:

>
>
> sent from a phone
>
> > On 29. Jun 2017, at 14:01, Rory McCann  wrote:
> >
> > When doing an import, it's important that someone does this sort of
> > work. That's part of the process of doing an import, to learn more about
> > the accuracy of the data you have, and to check how it would look after
> > you import it. You shouldn't just presume everything will fit together
> > 100%, someone needs to do this sort of analysis.
>
>
> yes, it will give you some indication about obvious or very likely errors,
> still there are also trees inside buildings, it is a rare situation, but I
> could recall several instances where I've seen it (both, buildings built
> around trees/leaving gaps/holes, and trees being planted inside buildings).
>
> Problems like these are obvious, but there's no indication that the rest
> of the trees are more correct, it might be just harder to spot the issues
> when the data seems fine on first glance.
>
> Are you local to the area? I'd look for some trees you know that fell in
> the past years and see whether these events are reflected.
>
> Cheers,
> Martin
>
>
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Ottawa, Canada Tree Import

[Rory McCann]

Hi.

I think there's been a misunderstand, maybe I'm not being clear.

I did some quick analysis of the data & current OSM data. There are
about 622 trees which are inside a building. about 300 which are <1m
from the centre line of a road.

For example there are some trees-inside-buildings around here (
https://www.openstreetmap.org/#map=17/45.39017/-75.75801 ) and (
https://www.openstreetmap.org/#map=16/45.4187/-75.7007 ). My JOSM
validator didn't flag "tree inside building", so you can't rely on that
to figure it out.

There are "trees very close to road centreline" around here (
https://www.openstreetmap.org/#map=18/45.28647/-75.70499 ) or (
https://www.openstreetmap.org/#map=18/45.40001/-75.75015 )

For a dataset of 150k, these numbers are pretty good.

When doing an import, it's important that someone does this sort of
work. That's part of the process of doing an import, to learn more about
the accuracy of the data you have, and to check how it would look after
you import it. You shouldn't just presume everything will fit together
100%, someone needs to do this sort of analysis.

I suggest you filter out the small number of suspicious trees, and
either manually enter them, change the OSM data, and/or contact the City
of Ottawa to tell them about possible errors in their data.

BTW I noticed there are lots of address interpolation ways from a 2011
CanVec import, and then lots of buildings with address tags from a
building import this year. The old address lines weren't removed, so I
think there are thousands (hundreds of thousands) of duplicate addresses
in Ottawa? Have you noticed this? This is a danger of doing an import
without looking at the existing OSM data.

Doing some data analysis isn't a "mechanical edit", you're looking at
the data, not editing it.

Rory

On 28/06/17 17:13, James wrote:
Other than MANUALLY VERIFYING EACH AND EVERY TREE, there is no way to 
give a statistical analysis of the accuracy of the entire dataset. If we 
did it programatically we'd have to prove how the method of analysis is 
correct and would be probably be brushed off as being a "mechanical 
edit" thus invalid. If the need to verify each tree is not on a 
road/water/building this could be accomplished during the import(what I 
like to call a manual import: where the data is validated at the time of 
the importation of data as to the accuracy of the location and not just 
a massive dump of data in one pass)


On Wed, Jun 28, 2017 at 11:02 AM, Rory McCann 
> wrote:


On 28/06/17 16:53, Kyle Nuttall wrote:

I am still a little confused by what you mean. Obviously if
there's a
  tree in the middle of a building, that means something is not
right.
But what I was trying to say was that the trees in this dataset will
only appear where an actual tree is in real life. There shouldn't be
any cases of rogue trees in the middle of rivers or buildings
because
a tree just wouldn't be there in real life.


What if OSM data is wrong? What if OSM says "The river bank goes up to
here" and it doesn't, and that would make the tree in the river.
Sometimes people just upload data into OSM without checking for things
like this, and you get these weird data problems. You should try to
figure where (if at all) this happens, and see if the problem is OSM or
the official data.

You're also presuming the official data is 100% guaranteed to have the
correct location. If they are 99.9% accurate, then there are 150 wrong
locations. 99.99% accurate, 15 wrong locations.

If you do this sort of analysis you can find out just how accurate the
official data is, and also prevent making the map be full of these
mistakes.



___
Imports mailing list
impo...@openstreetmap.org

https://lists.openstreetmap.org/listinfo/imports





--
外に遊びに行こう！


___
Imports mailing list
impo...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports





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

Re: [Talk-ca] [Imports] Ottawa, Canada Tree Import

[Martin Koppenhoefer]

sent from a phone

> On 29. Jun 2017, at 14:01, Rory McCann  wrote:
> 
> When doing an import, it's important that someone does this sort of
> work. That's part of the process of doing an import, to learn more about
> the accuracy of the data you have, and to check how it would look after
> you import it. You shouldn't just presume everything will fit together
> 100%, someone needs to do this sort of analysis.


yes, it will give you some indication about obvious or very likely errors, 
still there are also trees inside buildings, it is a rare situation, but I 
could recall several instances where I've seen it (both, buildings built around 
trees/leaving gaps/holes, and trees being planted inside buildings).

Problems like these are obvious, but there's no indication that the rest of the 
trees are more correct, it might be just harder to spot the issues when the 
data seems fine on first glance. 

Are you local to the area? I'd look for some trees you know that fell in the 
past years and see whether these events are reflected.

Cheers,
Martin 



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

Re: [Talk-ca] [Imports] Ottawa, Canada Tree Import

[Martin Koppenhoefer]

sent from a phone

> On 29. Jun 2017, at 13:07, James  wrote:
> 
> This is probably why dbh is used as the diameter only changes a tiny fraction 
> of the circumferance per year, so the data is less stale and you dont have to 
> audit them every year


there's really no difference, its exactly the same kind of data change (in %), 
as there's a linear relationship. The "tiny" fraction is 1/3.14
As the circumference are higher numbers (3 times), we would get more precision 
when keeping whole number values ;-)

cheers,
Martin 


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

Re: [Talk-ca] [Imports] Ottawa, Canada Tree Import

[James]

We are aware of the Canvec interpolations and cleaning them up(residential
areas with 100% coverage, we keep them in vast areas where new buildings
might be built as to not miss any potential areas) so that process is on
going...

On Thu, Jun 29, 2017 at 8:01 AM, Rory McCann  wrote:

> Hi.
>
> I think there's been a misunderstand, maybe I'm not being clear.
>
> I did some quick analysis of the data & current OSM data. There are
> about 622 trees which are inside a building. about 300 which are <1m
> from the centre line of a road.
>
> For example there are some trees-inside-buildings around here (
> https://www.openstreetmap.org/#map=17/45.39017/-75.75801 ) and (
> https://www.openstreetmap.org/#map=16/45.4187/-75.7007 ). My JOSM
> validator didn't flag "tree inside building", so you can't rely on that
> to figure it out.
>
> There are "trees very close to road centreline" around here (
> https://www.openstreetmap.org/#map=18/45.28647/-75.70499 ) or (
> https://www.openstreetmap.org/#map=18/45.40001/-75.75015 )
>
> For a dataset of 150k, these numbers are pretty good.
>
> When doing an import, it's important that someone does this sort of
> work. That's part of the process of doing an import, to learn more about
> the accuracy of the data you have, and to check how it would look after
> you import it. You shouldn't just presume everything will fit together
> 100%, someone needs to do this sort of analysis.
>
> I suggest you filter out the small number of suspicious trees, and
> either manually enter them, change the OSM data, and/or contact the City
> of Ottawa to tell them about possible errors in their data.
>
> BTW I noticed there are lots of address interpolation ways from a 2011
> CanVec import, and then lots of buildings with address tags from a
> building import this year. The old address lines weren't removed, so I
> think there are thousands (hundreds of thousands) of duplicate addresses
> in Ottawa? Have you noticed this? This is a danger of doing an import
> without looking at the existing OSM data.
>
> Doing some data analysis isn't a "mechanical edit", you're looking at
> the data, not editing it.
>
> Rory
>
> On 28/06/17 17:13, James wrote:
>
>> Other than MANUALLY VERIFYING EACH AND EVERY TREE, there is no way to
>> give a statistical analysis of the accuracy of the entire dataset. If we
>> did it programatically we'd have to prove how the method of analysis is
>> correct and would be probably be brushed off as being a "mechanical edit"
>> thus invalid. If the need to verify each tree is not on a
>> road/water/building this could be accomplished during the import(what I
>> like to call a manual import: where the data is validated at the time of
>> the importation of data as to the accuracy of the location and not just a
>> massive dump of data in one pass)
>>
>> On Wed, Jun 28, 2017 at 11:02 AM, Rory McCann > > wrote:
>>
>> On 28/06/17 16:53, Kyle Nuttall wrote:
>>
>> I am still a little confused by what you mean. Obviously if
>> there's a
>>   tree in the middle of a building, that means something is not
>> right.
>> But what I was trying to say was that the trees in this dataset
>> will
>> only appear where an actual tree is in real life. There shouldn't
>> be
>> any cases of rogue trees in the middle of rivers or buildings
>> because
>> a tree just wouldn't be there in real life.
>>
>>
>> What if OSM data is wrong? What if OSM says "The river bank goes up to
>> here" and it doesn't, and that would make the tree in the river.
>> Sometimes people just upload data into OSM without checking for things
>> like this, and you get these weird data problems. You should try to
>> figure where (if at all) this happens, and see if the problem is OSM
>> or
>> the official data.
>>
>> You're also presuming the official data is 100% guaranteed to have the
>> correct location. If they are 99.9% accurate, then there are 150 wrong
>> locations. 99.99% accurate, 15 wrong locations.
>>
>> If you do this sort of analysis you can find out just how accurate the
>> official data is, and also prevent making the map be full of these
>> mistakes.
>>
>>
>>
>> ___
>> Imports mailing list
>> impo...@openstreetmap.org
>> 
>> https://lists.openstreetmap.org/listinfo/imports
>> 
>>
>>
>>
>>
>> --
>> 外に遊びに行こう！
>>
>>
>> ___
>> Imports mailing list
>> impo...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
>>
>>
>
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>



-- 
外に遊びに行こう！

Re: [Talk-ca] [Imports] Ottawa, Canada Tree Import

[Denis Carriere]

Thanks Rory,

Knowing that there's 622 trees in buildings is good information, the import
should definitely have a look at those specific trees and exclude them from
the import (tackling them manually is a good idea).

The building interpolation & building address issue should be discussed as
a separate thread.


*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

On Thu, Jun 29, 2017 at 8:01 AM, Rory McCann  wrote:

> Hi.
>
> I think there's been a misunderstand, maybe I'm not being clear.
>
> I did some quick analysis of the data & current OSM data. There are
> about 622 trees which are inside a building. about 300 which are <1m
> from the centre line of a road.
>
> For example there are some trees-inside-buildings around here (
> https://www.openstreetmap.org/#map=17/45.39017/-75.75801 ) and (
> https://www.openstreetmap.org/#map=16/45.4187/-75.7007 ). My JOSM
> validator didn't flag "tree inside building", so you can't rely on that
> to figure it out.
>
> There are "trees very close to road centreline" around here (
> https://www.openstreetmap.org/#map=18/45.28647/-75.70499 ) or (
> https://www.openstreetmap.org/#map=18/45.40001/-75.75015 )
>
> For a dataset of 150k, these numbers are pretty good.
>
> When doing an import, it's important that someone does this sort of
> work. That's part of the process of doing an import, to learn more about
> the accuracy of the data you have, and to check how it would look after
> you import it. You shouldn't just presume everything will fit together
> 100%, someone needs to do this sort of analysis.
>
> I suggest you filter out the small number of suspicious trees, and
> either manually enter them, change the OSM data, and/or contact the City
> of Ottawa to tell them about possible errors in their data.
>
> BTW I noticed there are lots of address interpolation ways from a 2011
> CanVec import, and then lots of buildings with address tags from a
> building import this year. The old address lines weren't removed, so I
> think there are thousands (hundreds of thousands) of duplicate addresses
> in Ottawa? Have you noticed this? This is a danger of doing an import
> without looking at the existing OSM data.
>
> Doing some data analysis isn't a "mechanical edit", you're looking at
> the data, not editing it.
>
> Rory
>
> On 28/06/17 17:13, James wrote:
>
>> Other than MANUALLY VERIFYING EACH AND EVERY TREE, there is no way to
>> give a statistical analysis of the accuracy of the entire dataset. If we
>> did it programatically we'd have to prove how the method of analysis is
>> correct and would be probably be brushed off as being a "mechanical edit"
>> thus invalid. If the need to verify each tree is not on a
>> road/water/building this could be accomplished during the import(what I
>> like to call a manual import: where the data is validated at the time of
>> the importation of data as to the accuracy of the location and not just a
>> massive dump of data in one pass)
>>
>> On Wed, Jun 28, 2017 at 11:02 AM, Rory McCann > > wrote:
>>
>> On 28/06/17 16:53, Kyle Nuttall wrote:
>>
>> I am still a little confused by what you mean. Obviously if
>> there's a
>>   tree in the middle of a building, that means something is not
>> right.
>> But what I was trying to say was that the trees in this dataset
>> will
>> only appear where an actual tree is in real life. There shouldn't
>> be
>> any cases of rogue trees in the middle of rivers or buildings
>> because
>> a tree just wouldn't be there in real life.
>>
>>
>> What if OSM data is wrong? What if OSM says "The river bank goes up to
>> here" and it doesn't, and that would make the tree in the river.
>> Sometimes people just upload data into OSM without checking for things
>> like this, and you get these weird data problems. You should try to
>> figure where (if at all) this happens, and see if the problem is OSM
>> or
>> the official data.
>>
>> You're also presuming the official data is 100% guaranteed to have the
>> correct location. If they are 99.9% accurate, then there are 150 wrong
>> locations. 99.99% accurate, 15 wrong locations.
>>
>> If you do this sort of analysis you can find out just how accurate the
>> official data is, and also prevent making the map be full of these
>> mistakes.
>>
>>
>>
>> ___
>> Imports mailing list
>> impo...@openstreetmap.org
>> 
>> https://lists.openstreetmap.org/listinfo/imports
>> 
>>
>>
>>
>>
>> --
>> 外に遊びに行こう！
>>
>>
>> ___
>> Imports mailing list
>> impo...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
>>
>>
>
>
> ___
> 

Re: [Talk-ca] [Imports] Ottawa, Canada Tree Import

[James]

This is probably why dbh is used as the diameter only changes a tiny
fraction of the circumferance per year, so the data is less stale and you
dont have to audit them every year

On Jun 28, 2017 9:21 PM, "Max Erickson"  wrote:

>
>
> On Jun 28, 2017 6:46 PM, "Kyle Nuttall"  wrote:
>
> The biggest issue to resolve is tagging the thickness of the trees. The
> data was provided as the diameter measured in centimeters. I understand
> that the circumference tag was made for ease of use, but anyone that is
> collecting data specifically for trees would know the concept of Diameter
> at Breast Height. It's my belief that the more the data is manipulated, the
> more errors that are introduced. If converting a DBH of 9cm to
> circumference in meters, you get 0.2827433388230814...m. How many digits
> is sufficient for accuracy? I suppose 0.001m would as much as needed.
>
>
> A sensible conversion shouldn't imply such a precise result. Round
> instead. Not quite following the rules for significant figures, a 9 cm dbh
> becomes a 0.28 m circumference ( which round trips back to 9 cm using the
> same vaguely sloppy method).
>
> On the other hand, given the morphology of trees and wide use of dbh in
> biology, I think it makes sense to use it. In taginfo, centimeter seems to
> be the more used unit. Explicit units in the value, like dbh=9 cm makes
> more sense to me than putting the unit in the tag (which invites nonsense
> like divergent values).
>
> Overall, I sort of question the value of putting the stem size in osm.
> Mostly because the data is fairly likely to go stale as the trees grow (so
> anyone who really cares for it is best off going to the source).
>
> Max
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca