[Talk-ca] Building Import update
Nate Wessel
bike756 at gmail.com
Sun Jan 27 00:48:58 UTC 2019
James,
It does seem that someone will need to properly simplify the data since
you don't seem willing to do the necessary work. I've already offered to
help, but I can't do it today, or tomorrow for that matter. My
suggestion, again, is that we slow down and take the time to do this
right. Rushing ahead can only lead to hurt feelings, angry emails, and
extra work for everyone. Given how much editing goes on in the areas I
know, many of these imported buildings might not be touched again for
another decade - can't we make them right the first time?
I think Pierre is on the right track here with his thoughtful analysis
of the buildings that have been imported so far - this is the kind of
stuff that I'm talking about when I say we need some validation. Some
questions that I'd like to see answered (Pierre, when you have some more
time!): just how many buildings imported so far are not orthogonal, but
seem like they should be? What percentage of buildings would benefit
from simplification, and is the problem worse/better in some areas
compared to others?
I actually don't think the problem is technically difficult to solve -
we just have to understand the nature and extent off the problem before
we rush to solutions. That's the point of validation - understanding
what the problems are.
Best,
Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com <http://natewessel.com>
On 1/26/19 2:10 PM, James wrote:
> I'm not installing postgesql for you to accept simplification, that
> YOU said was required because there were 2x as many points(which was
> proved wrong via the simplification) If you want to have fun with the
> file, go a head.
>
> On Sat., Jan. 26, 2019, 2:00 p.m. Nate Wessel <bike756 at gmail.com
> <mailto:bike756 at gmail.com> wrote:
>
> Building count doesn't really have anything to do with preserving
> topology, and I'm not sure a visual inspection would cut it - Can
> you look at the documentation for this tool and verify that it
> preserves the topology of polygon layers?
>
> This is a good illustration of the (potential) problem:
> https://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyPreserveTopology
>
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban
> Planning
> NateWessel.com <http://natewessel.com>
>
> On 1/26/19 12:31 PM, James wrote:
>> it does if you saw my analysis of building(polygon count) remains
>> the same also visually inspected a few and there was preservation
>> of them
>>
>> On Sat., Jan. 26, 2019, 11:43 a.m. Nate Wessel <bike756 at gmail.com
>> <mailto:bike756 at gmail.com> wrote:
>>
>> Does that preserve topology between buildings that share nodes?
>>
>> Nate Wessel
>> Jack of all trades, Master of Geography, PhD candidate in
>> Urban Planning
>> NateWessel.com <http://natewessel.com>
>>
>> On 1/26/19 11:31 AM, James wrote:
>>> no need for scripts, qgis does this fine via the Vector
>>> menu -> Geometry tools -> Simplify Geometries utility. I
>>> simplified it to 20cm with the , but I think 40cm is too
>>> aggressive.
>>>
>>> I already have scripts to compile it into the dataformat
>>> needed to be served.
>>>
>>> On Sat., Jan. 26, 2019, 11:16 a.m. Nate Wessel
>>> <bike756 at gmail.com <mailto:bike756 at gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> The wiki page is indeed looking a whole lot better right
>>> now - my thanks and congrats to everyone who
>>> contributed! There is a still a ways to go, but we seem
>>> to be getting there quickly.
>>>
>>> I'll echo John in saying that I would appreciate hearing
>>> from some of the other people who chimed in to express
>>> their doubts about the import. For my part, I'm not
>>> satisfied yet - no surprise, I'm sure ;-). I'm thrilled
>>> that we're talking and working together in the open, and
>>> that addresses the biggest concern I had with the import.
>>>
>>> These are the big issues I see remaining:
>>>
>>> 1. *Validation*: Ideally I'd like to see a good chunk
>>> (more than half) of the data that has been imported
>>> already validated by another user before we proceed with
>>> importing more data. Validation is part of the import
>>> plan, so the import isn't done until validation is done
>>> anyway. My hope is that this will flag any issues that
>>> we can fix before moving forward, and give people time
>>> to chime in on the import plan who maybe haven't
>>> already. I don't want to see everything imported and
>>> only then do we start systematically checking the
>>> quality of our work, if ever. If no one wants to do it
>>> now, no one is going to want to do it later either, and
>>> that doesn't bode well.
>>>
>>> 2. *Simplification*: James' analysis showed that
>>> simplification could save several hundred megabytes (and
>>> probably more) in Ontario alone. This is totally worth
>>> doing, but we have to document the process and be very
>>> careful not to lose valuable data. I believe there was
>>> also a concern raised about orthogonal buildings being
>>> not quite orthogonal - this is something that we should
>>> handle at the same time, again, very carefully. We
>>> certainly don't want to coerce every building into right
>>> angles. With respect to James, I'm not sure this is
>>> something that can be done with a few clicks in QGIS. I
>>> would be willing to develop a script to handle this, but
>>> it would take me about a week or two to find the time to
>>> do this properly. We would need to simultaneously A)
>>> simplify straight lines B) orthogonalize where possible
>>> and C) preserve topology between connected buildings.
>>> This is not impossible, it just takes time and care to
>>> do correctly.
>>>
>>> 3. *Speed and Size*: To John's point, it seems like
>>> people certainly are not sticking to the areas they
>>> know, unless they get around a whole hell of a lot more
>>> than I do, and yes this is a problem. The whole Toronto
>>> region was basically imported by two people: DannyMcD
>>> seems to have done the entire west side of the region
>>> (hundreds of square kilometers) while zzptichka imported
>>> the entire east side of the region (again a truly
>>> massive area), both in the matter of a week or two. They
>>> only stopped in the middle where there were more
>>> buildings already and things got a bit more difficult.
>>> The middle is where I live, and when I saw that wave of
>>> buildings coming, I sounded the alarms.
>>> This is way too fast - no one person should be able to
>>> import the GTA in a couple weeks. A big part of the
>>> problem, IMO is that the task squares are much too
>>> large, and allow/require a user to import huge areas at
>>> once. At the least, some of the task squares in central
>>> Toronto are impossibly large, including hundreds or
>>> thousands of buildings already mapped in OSM. Conflation
>>> on these, if done properly would take the better part of
>>> a day, and people are likely to get sloppy.
>>> I would like to see the task squares dramatically
>>> reduced in size as a way of slowing people down, helping
>>> them stick to areas they know well, and keeping them
>>> focused on data quality over quantity. This would also
>>> make the process much more accessible to local mappers
>>> who don't already have tons of experience importing.
>>>
>>> 4. *Conflation*: I don't think the current conflation
>>> plan is adequate(ly documented). In practice, what
>>> people are actually doing may be fine, but I really want
>>> to see some better thought on how to handle existing
>>> buildings. Right now the wiki says for example "/Before
>>> merging buildings data switch to OSM layer and see if
>>> there are any clusters of buildings without any
>>> meaningful tags you can delete to save time when merging/."
>>> With respect to whoever wrote this, this approach seems
>>> to value time over data integrity and I just don't think
>>> that's how OSM should operate. We need to be more
>>> careful with the existing data, and we need to show that
>>> care with clear and acceptable guidelines for handling
>>> the data that countless people have already spent their
>>> time contributing. We don't do OSM any favours by
>>> carelessly deleting and replacing data. Help convince me
>>> that this isn't what's happening.
>>>
>>> Until some effort has been made to address these
>>> concerns, I will continue to oppose this import moving
>>> forward. And to be clear, I don't want to oppose this
>>> import - I have too much else I should be focusing on. I
>>> just don't want to see another shoddy import in Toronto
>>> (or elsewhere).
>>>
>>> Best,
>>>
>>> Nate Wessel
>>> Jack of all trades, Master of Geography, PhD candidate
>>> in Urban Planning
>>> NateWessel.com <http://natewessel.com>
>>>
>>> On 1/26/19 8:49 AM, john whelan wrote:
>>>> I'm not certain how this addresses the concerns raised
>>>> by Andrew Lester and
>>>>
>>>> Pierre Béland,
>>>>
>>>> and I seem to recall one other person who expressed
>>>> concerns.
>>>>
>>>> I think it is important that their concerns are addressed.
>>>>
>>>> Perhaps they would be kind enough to comment on whether
>>>> or not this approach addresses their concerns.
>>>>
>>>> Do we have a concern that some mappers have been
>>>> importing buildings further than say twenty
>>>> kilometers from where they live?
>>>>
>>>>
>>>> Have you found volunteers of local mappers in
>>>> Alberta
>>>> British Columbia
>>>> Manitoba
>>>> New Brunswick
>>>> Newfoundland and Labrador
>>>> Northwest Territories
>>>> Nova Scotia
>>>> Nunavut
>>>> Ontario
>>>> Prince Edward Island
>>>> Quebec
>>>> Saskatchewan
>>>> Yukon
>>>>
>>>> Who will be willing to oversee the import in each province?
>>>>
>>>> Does this mean the smaller provinces may not see any data?
>>>>
>>>> How will you handle cities of say 80,000 population in
>>>> a smaller province who have an interest in seeing their
>>>> buildings available but have no idea on how to contact
>>>> the provincial group?
>>>>
>>>>
>>>>
>>>> If we go back to earlier times it was a suggestion in
>>>> talk-ca that we use the single import approach and it
>>>> was mentioned at the time there didn't seem to be a
>>>> list of local mapper groups in Canada.
>>>>
>>>> I'm not saying the approach of a single import as far
>>>> as the import list and talk-ca followed by a procedure
>>>> of locally organised mappers bringing in the data is
>>>> wrong I'm just trying to ensure the project moves
>>>> forward and we are in agreement.
>>>>
>>>> Thanks
>>>>
>>>> Cheerio John
>>>>
>>>> On Sat, 26 Jan 2019 at 00:17, OSM Volunteer stevea
>>>> <steveaOSM at softworkers.com
>>>> <mailto:steveaOSM at softworkers.com>> wrote:
>>>>
>>>> Thanks to some good old-fashioned OSM
>>>> collaboration, both the
>>>> https://wiki.osm.org/wiki/Canada_Building_Import
>>>> and
>>>> https://wiki.osm.org/wiki/WikiProject_Canada/Building_Canada_2020#NEWS.2C_January_2019
>>>> have been updated. (The latter points to the former).
>>>>
>>>> In short, it says there are now step-by-steps to
>>>> begin an import for a particular province, and that
>>>> as the steps get fine-tuned (they look good, but
>>>> might get minor improvements), building a community
>>>> of at least one or two mappers in each of the
>>>> provinces with data available, the Tasking Manager
>>>> can and will lift the "On Hold" or "Stopped" status.
>>>>
>>>> Nice going, Canada!
>>>>
>>>> See you later,
>>>>
>>>> SteveA
>>>> California
>>>> _______________________________________________
>>>> Talk-ca mailing list
>>>> Talk-ca at openstreetmap.org
>>>> <mailto:Talk-ca at openstreetmap.org>
>>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>>
>>>>
>>>> _______________________________________________
>>>> Talk-ca mailing list
>>>> Talk-ca at openstreetmap.org <mailto:Talk-ca at openstreetmap.org>
>>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>> _______________________________________________
>>> Talk-ca mailing list
>>> Talk-ca at openstreetmap.org <mailto:Talk-ca at openstreetmap.org>
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>> _______________________________________________
>> Talk-ca mailing list
>> Talk-ca at openstreetmap.org <mailto:Talk-ca at openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org <mailto:Talk-ca at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-ca
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20190126/d1b7561a/attachment-0001.html>
More information about the Talk-ca
mailing list