Sounds very reasonable to me. Thanks John
On Sat, 18 Jan 2020 at 20:02, Nate Wessel <bike...@gmail.com> wrote: > In short, yes. But we should give them a clear option and a clear path > toward doing it either way - written procedures, provide preprocessing > scripts/help, etc. > > Best, > > Nate Wessel, PhD > Planner, Cartographer, Transport Nerd > NateWessel.com <https://www.natewessel.com> > On 2020-01-18 7:37 p.m., john whelan wrote: > > > 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 >
_______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
