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 <bike...@gmail.com
<mailto:bike...@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
<stevea...@softworkers.com
<mailto:stevea...@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@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-ca
_______________________________________________
Talk-ca mailing list
Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-ca
_______________________________________________
Talk-ca mailing list
Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-ca
