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

[James]

>But i understand that as Canadians you have a reputation to defend - i
>mean with marvels like this:

>http://www.openstreetmap.org/#map=18/45.40668/-75.66268

You are assuming that we had the most up to date imagery at all times, but
the problem is that a local mapper could tell you that the imagery was only
recently updated(see previous imagery: http://imgur.com/a/zRia5). A local
mapper could also tell you that schools here are not like european schools,
as in they rent/buy portables (
http://schoolportable.com/wp-content/uploads/2010/08/1buildingtan24x32icon.jpg)
which can be installed/removed based on school registration/capacity. So
portables in a soccer field is not uncommon here. There's an expression in
English: When you "assume" you only make an "ass" of "u" and "me".

I must also ask you Christoph to remain respectful on the mailing list and
not generilize for an entire country, we can easily make generilizations
about Germany as well, but it's non-constructive and counter-productive and
creates a toxic enviroment for the community.

Bye.



On Tue, Jul 4, 2017 at 4:32 AM, Christoph Hormann  wrote:

> On Tuesday 04 July 2017, Kyle Nuttall wrote:
> >
> > Hopefully we've resolved most of the issues [...]
>
> I don't think so.
>
> The buildings were just an example for possible incompatibilities.  If
> there are 200 of those there are almost certainly also at least several
> hundred others - like the too close proximity to roads issue Rory
> mentioned or other areas incompatible with the presence of trees.
>
> The english species names in the table seem wrong - AFAIK it is "Red
> Oak", not "Oak Red" - see
> https://wiki.openstreetmap.org/wiki/Key:species
>
> The tag you plan to use for the size of the trunk is still undocumented.
>
> But i understand that as Canadians you have a reputation to defend - i
> mean with marvels like this:
>
> http://www.openstreetmap.org/#map=18/45.40668/-75.66268
>
> it would be a shame if similar things were not possible for trees as
> well...
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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

[Kyle Nuttall]

After some data analysis (cheers Denis) we've found about 200 trees that are 
conflicting with buildings. These will obviously need to be handled manually 
which should be an easy task for the local mappers.

The wiki page has been updated accordingly.

Hopefully we've resolved most of the issues as we'd like to get this started by 
Friday.

Happy Canada 150 weekend
Kyle
___
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] [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

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

[James]

If you can assume that OSM data is 100% correct then you can also assume
that data from a city GIS department that have done their jobs correctly is
also 100% correct.

On Wed, Jun 28, 2017 at 12:04 PM, James  wrote:

> Rory said:
> 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.
>
> Which is a valid point because you are suggesting:
> The usual approach would be to automatically analyze the data in
> combination with the OSM data to identify the cases with possible
> conflicts and then to manually review only those.
>
> To which I am replying that is an invalid way of validating data because
> that would be a presumtion that OSM Data is 100% correct and accurate,
> which it is not(aligned to misaligned imagery is an example of why it could
> be incorrect).
>
> Maybe understanding the logic flaw I'm trying to express in your
> "analysis" would be a good place to start.
>
>
> On Wed, Jun 28, 2017 at 11:56 AM, Christoph Hormann 
> wrote:
>
>> On Wednesday 28 June 2017, James wrote:
>> > Well that analysis is incorrect in itself as others have stated, OSM
>> > can be wrong. So a river bank, building, etc may not be properly
>> > drawn. So with that being said what you are saying is the only viable
>> > way to accept an import is to manually review every single item in
>> > the dataset.
>>
>> It would not be a bad idea to actually read what i write before claiming
>> it means something different than what i said.
>>
>> --
>> Christoph Hormann
>> http://www.imagico.de/
>>
>> ___
>> 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

[James]

Rory said:
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.

Which is a valid point because you are suggesting:
The usual approach would be to automatically analyze the data in
combination with the OSM data to identify the cases with possible
conflicts and then to manually review only those.

To which I am replying that is an invalid way of validating data because
that would be a presumtion that OSM Data is 100% correct and accurate,
which it is not(aligned to misaligned imagery is an example of why it could
be incorrect).

Maybe understanding the logic flaw I'm trying to express in your "analysis"
would be a good place to start.


On Wed, Jun 28, 2017 at 11:56 AM, Christoph Hormann  wrote:

> On Wednesday 28 June 2017, James wrote:
> > Well that analysis is incorrect in itself as others have stated, OSM
> > can be wrong. So a river bank, building, etc may not be properly
> > drawn. So with that being said what you are saying is the only viable
> > way to accept an import is to manually review every single item in
> > the dataset.
>
> It would not be a bad idea to actually read what i write before claiming
> it means something different than what i said.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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

[James]

Well that analysis is incorrect in itself as others have stated, OSM can be
wrong. So a river bank, building, etc may not be properly drawn. So with
that being said what you are saying is the only viable way to accept an
import is to manually review every single item in the dataset.

On Wed, Jun 28, 2017 at 11:24 AM, Christoph Hormann  wrote:

> On Wednesday 28 June 2017, Kyle Nuttall wrote:
> > [...]
> >
> > I guess the most likely scenario would be a tree that had been cut
> > down in the last 4 years and a building placed where the tree
> > previously was. In that case, using various imagery (Bing,
> > DigitalGlobe, OSC, Mapillary, etc.) would be used to verify that the
> > tree no longer stands and should be removed before adding it to the
> > map.
>
> All very well - but with 150k trees you need some plan how you do this,
> as said manually reviewing all 150k to find maybe a few hundred ones
> that require manual corrections is not a realistic plan.
>
> The usual approach would be to automatically analyze the data in
> combination with the OSM data to identify the cases with possible
> conflicts and then to manually review only those.
>
> If you don't feel confident in doing this yourself ask around if someone
> can help you with that (with all the '+1'-sayers this should not be a
> problem...)
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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

[James]

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
>



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