<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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?<br>
<br>
This is a good illustration of the (potential) problem:<br>
<a class="moz-txt-link-freetext" href="https://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyPreserveTopology">https://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyPreserveTopology</a><br>
</p>
<div class="moz-signature">Nate Wessel<br>
<span style="font-size:10px;color:#777">Jack of all trades, Master
of Geography, PhD candidate in Urban Planning<br>
<a href="http://natewessel.com">NateWessel.com</a></span>
<br>
<br>
</div>
<div class="moz-cite-prefix">On 1/26/19 12:31 PM, James wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CANk4qi-6PKcW+68KYhbJF5-nOm2ABc219Wo=97bVUQJXjDeftg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">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 </div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Sat., Jan. 26, 2019, 11:43 a.m. Nate Wessel
<<a href="mailto:bike756@gmail.com" moz-do-not-send="true">bike756@gmail.com</a>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Does that preserve topology between buildings that share
nodes?<br>
</p>
<div class="m_-1392011054493208153moz-signature">Nate Wessel<br>
<span style="font-size:10px;color:#777">Jack of all
trades, Master of Geography, PhD candidate in Urban
Planning<br>
<a href="http://natewessel.com" target="_blank"
rel="noreferrer" moz-do-not-send="true">NateWessel.com</a></span>
<br>
<br>
</div>
<div class="m_-1392011054493208153moz-cite-prefix">On
1/26/19 11:31 AM, James wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">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.
<div dir="auto"><br>
</div>
<div dir="auto">I already have scripts to compile it
into the dataformat needed to be served.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Sat., Jan. 26, 2019, 11:16 a.m. Nate
Wessel <<a href="mailto:bike756@gmail.com"
target="_blank" rel="noreferrer"
moz-do-not-send="true">bike756@gmail.com</a> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Hi all,</p>
<p>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. <br>
</p>
<p>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. <br>
</p>
<p>These are the big issues I see remaining: <br>
</p>
<p>1. <b>Validation</b>: 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.<br>
</p>
<p>2. <b>Simplification</b>: 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.<br>
</p>
<p>3. <b>Speed and Size</b>: 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. <br>
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. <br>
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.<br>
</p>
<p>4. <b>Conflation</b>: 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 "<i>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</i>."<br>
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.<br>
</p>
<p>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). <br>
</p>
<p>Best,<br>
</p>
<div
class="m_-1392011054493208153m_-501377306698867165moz-signature">Nate
Wessel<br>
<span style="font-size:10px;color:#777">Jack of
all trades, Master of Geography, PhD candidate
in Urban Planning<br>
<a href="http://natewessel.com" rel="noreferrer
noreferrer" target="_blank"
moz-do-not-send="true">NateWessel.com</a></span>
<br>
<br>
</div>
<div
class="m_-1392011054493208153m_-501377306698867165moz-cite-prefix">On
1/26/19 8:49 AM, john whelan wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small">I'm
not certain how this addresses the concerns
raised by <span
style="font-family:Arial,Helvetica,sans-serif">Andrew
Lester and </span></div>
<table
class="m_-1392011054493208153m_-501377306698867165gmail-ajC"
cellpadding="0">
<tbody>
<tr
class="m_-1392011054493208153m_-501377306698867165gmail-UszGxc
m_-1392011054493208153m_-501377306698867165gmail-ajv">
<td colspan="2"
class="m_-1392011054493208153m_-501377306698867165gmail-gG"><span
class="m_-1392011054493208153m_-501377306698867165gmail-gI"></span><br>
</td>
<td colspan="2"
class="m_-1392011054493208153m_-501377306698867165gmail-gL"><span
class="m_-1392011054493208153m_-501377306698867165gmail-gI"><span
class="m_-1392011054493208153m_-501377306698867165gmail-qu"><span
name="Pierre Béland via Talk-ca"
class="m_-1392011054493208153m_-501377306698867165gmail-gD">Pierre
Béland<span
class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small">,
</span></span></span></span></td>
</tr>
</tbody>
</table>
<span class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small">and
I seem to recall one other person who
expressed concerns.</span></div>
<div dir="ltr"><font face="verdana, sans-serif"><br>
</font></div>
<div dir="ltr"><font face="verdana, sans-serif"><span
class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small">I
think it is important that their concerns
are addressed.</span></font></div>
<div dir="ltr"><font face="verdana, sans-serif"><span
class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small"><br>
</span></font></div>
<div dir="ltr"><font face="verdana, sans-serif"><span
class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small">Perhaps
they would be kind enough to comment on
whether or not this approach addresses
their concerns.</span></font></div>
<div dir="ltr"><font face="verdana, sans-serif"><br>
</font></div>
<div dir="ltr"><font face="verdana, sans-serif"><span
class="gmail_default">Do we have a concern
that some mappers have been importing
buildings further than say twenty
kilometers from where they live?</span><br>
</font><br>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small">Have
you found volunteers of local mappers in </div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small">
<div class="gmail_default">Alberta</div>
<div class="gmail_default">British Columbia</div>
<div class="gmail_default">Manitoba</div>
<div class="gmail_default">New Brunswick</div>
<div class="gmail_default">Newfoundland and
Labrador</div>
<div class="gmail_default">Northwest
Territories</div>
<div class="gmail_default">Nova Scotia</div>
<div class="gmail_default">Nunavut</div>
<div class="gmail_default">Ontario</div>
<div class="gmail_default">Prince Edward
Island</div>
<div class="gmail_default">Quebec</div>
<div class="gmail_default">Saskatchewan</div>
<div class="gmail_default">Yukon</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">Who will be
willing to oversee the import in each
province?</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">Does this mean
the smaller provinces may not see any
data?</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">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?</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">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.</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">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. </div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">Thanks </div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">Cheerio John</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr"
class="m_-1392011054493208153m_-501377306698867165gmail_attr">On
Sat, 26 Jan 2019 at 00:17, OSM Volunteer
stevea <<a
href="mailto:steveaOSM@softworkers.com"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">steveaOSM@softworkers.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Thanks to
some good old-fashioned OSM collaboration,
both the <a
href="https://wiki.osm.org/wiki/Canada_Building_Import"
rel="noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true">https://wiki.osm.org/wiki/Canada_Building_Import</a>
and <a
href="https://wiki.osm.org/wiki/WikiProject_Canada/Building_Canada_2020#NEWS.2C_January_2019"
rel="noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true">https://wiki.osm.org/wiki/WikiProject_Canada/Building_Canada_2020#NEWS.2C_January_2019</a>
have been updated. (The latter points to the
former).<br>
<br>
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.<br>
<br>
Nice going, Canada!<br>
<br>
See you later,<br>
<br>
SteveA<br>
California<br>
_______________________________________________<br>
Talk-ca mailing list<br>
<a href="mailto:Talk-ca@openstreetmap.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">Talk-ca@openstreetmap.org</a><br>
<a
href="https://lists.openstreetmap.org/listinfo/talk-ca"
rel="noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/talk-ca</a><br>
</blockquote>
</div>
<br>
<fieldset
class="m_-1392011054493208153m_-501377306698867165mimeAttachmentHeader"></fieldset>
<pre class="m_-1392011054493208153m_-501377306698867165moz-quote-pre">_______________________________________________
Talk-ca mailing list
<a class="m_-1392011054493208153m_-501377306698867165moz-txt-link-abbreviated" href="mailto:Talk-ca@openstreetmap.org" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">Talk-ca@openstreetmap.org</a>
<a class="m_-1392011054493208153m_-501377306698867165moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-ca" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/talk-ca</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Talk-ca mailing list<br>
<a href="mailto:Talk-ca@openstreetmap.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">Talk-ca@openstreetmap.org</a><br>
<a
href="https://lists.openstreetmap.org/listinfo/talk-ca"
rel="noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/talk-ca</a><br>
</blockquote>
</div>
</blockquote>
</div>
_______________________________________________<br>
Talk-ca mailing list<br>
<a href="mailto:Talk-ca@openstreetmap.org" target="_blank"
rel="noreferrer" moz-do-not-send="true">Talk-ca@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-ca"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/talk-ca</a><br>
</blockquote>
</div>
</blockquote>
</body>
</html>