> But also - sorry this is such a long email - we certainly should not be
manually doing re-conflation where buildings are very dense (e.g. downtown
Toronto) or where they have already been imported extensively (much of the
rest of the GTA). The import plan I'm working on for Toronto will take care
of most of this automatically by importing only in the sparse gaps between
existing OSM buildings. For other parts of Canada, this may not be much of
an issue at all - I wouldn't know.

My interpretation is you're happy to leave this call to the local
coordinator?  If they have no buildings it's fairly simple if there are
buildings already mapped it becomes more complex.

Thanks John

On Sat, 18 Jan 2020 at 19:12, Nate Wessel <bike...@gmail.com> wrote:

> Hi all,
>
> Daniel, thanks for continuing to prod the conversation along :-)
>
> I guess the point of disagreement here is that I generally don't agree
> that the ODB buildings are of higher quality than what's already in OSM.
> The ODB data I've seen is quite messy, and IMO only marginally better than
> having no data in an area, especially if not properly checked and conflated
> with surrounding OSM data. People seem to generally disagree with that
> perspective though, so I'll assume that other areas are better represented
> by their respective ODB data sources. Central Toronto may just not have
> been well mapped by the City's GIS dept; it certainly isn't the easiest
> thing to get right.
>
> My real worry here is that someone will be carelessly going through an
> import replacing geometries and will destroy the work of an editor like
> myself who carefully contributed their time to make a neat and accurate
> map. I know for certain I've contributed better data in Toronto than what's
> available from government sources for the same area.
>
> We must recall that governments produce building footprints in the same
> way that we do - usually by tracing imagery, and there is little reason to
> suppose that their data is better or more accurate just because it comes
> from a seemingly authoritative source. It comes from interns - likely
> interns with outdated software and low-resolution surveys.
>
> All that being said, I think my real reluctance to go with the flow here
> stems from the haste and carelessness of the original importers in the GTA.
> We're working toward a process that should be very different from theirs
> though and I probably need to just trust that our process will be calmer,
> slower, and more thoughtful. If it is, I can get on board.
>
> But also - sorry this is such a long email - we certainly should not be
> manually doing re-conflation where buildings are very dense (e.g. downtown
> Toronto) or where they have already been imported extensively (much of the
> rest of the GTA). The import plan I'm working on for Toronto will take care
> of most of this automatically by importing only in the sparse gaps between
> existing OSM buildings. For other parts of Canada, this may not be much of
> an issue at all - I wouldn't know.
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com <https://www.natewessel.com>
> On 2020-01-18 5:24 p.m., Daniel @jfd553 wrote:
>
> Bonjour groupe,
>
> Here is a sequential summary of the last exchanges. I inserted some
> comments […] within these exchanges description and summarize what I
> understand from it at the end.
>
> *Nate* asked not to confuse the process of importing new data with that
> of updating/modifying existing OSM data in order to keep things simple for
> this import.
>
> *Daniel* (I) responded that importing new data and updating/modifying
> existing ones at the same time (when necessary) is not unusual in OSM [*and
> would be more efficient*].
>
> *John* replied that importing new data and updating/modify existing data
> when required worked quite nicely when importing Ottawa.
>
> *Nate *explained he believes that the buildings will not be compared
> manually since there are hundreds of thousands of them in OSM for Toronto
> alone. In other words, he thinks there will be automated edits, and these
> edits are not governed by the same policies as imports. [*This is an
> important consideration. What has happened in Ottawa and Toronto so far?
> Have automatic processes been used?*]
>
> *Tim* replied that in most cases it might be appropriate to replace OSM
> data, as he believes [*as I do for most of the cases*] that the ODB
> footprints will be more accurate than existing buildings. However he
> considers it is a case-by-case decision [*then no automation process
> should be used*].
>
> *John* couldn’t resist digressing toward the “Microsoft buildings import”
> but had to bring back the discussion on ODB import after reactions from
> *Tim* and *Pierre* (LOL).
>
>
>
> I think that, somehow, we could all agree on how the import should be done:
>
> -          Align images on ODB, unless evidence ODB data are ill located.
>
> -          Align existing OSM content with the image, *only* if necessary
> after aligning the image with ODB.
>
> -          Import non-existent buildings in OSM.
>
> -          Conflate ODB and OSM buildings, *only* if necessary.
>
> -
>
> To address Nate’s legitimate concerns, we could agree that there will be
> *no* automatic changes/conflation of existing buildings. Having a local
> import manager and by using the task manager, we should be able to ensure
> that there will be no unauthorized import (i.e. not responding to the
> above).
>
> Am I too optimistic?
>
> Daniel
>
>
>
>
>
> _______________________________________________
> Talk-ca mailing 
> listTalk-ca@openstreetmap.orghttps://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

Reply via email to