That is incorrect, some building parts could be bigger if they are
surrounding the building as an overhang etc. You can't assume building will
be bigger
On Thu., Jan. 24, 2019, 11:51 a.m. Nate Wessel Is it sufficient to tag fragments as building:part without indicating
> which part or how many
>>It looks like perhaps we might just have to find the largest part for the
footprint (building=yes) and any intersecting smaller buildings
(building:part=yes).
Yes, that's what I usually do. I also sometimes delete non-important
building parts that don't add anything valuable to the map but only
Data is currently stored in OSM by mappers this way, regardless of the
source. I don't think a height or which part is needed to use the building
part tags. It provides the basis for later additions should a mapper be so
inclined to add it.
---
Kevin Farrugia
On Thu., Jan. 24, 2019, 11:51
Is it sufficient to tag fragments as building:part without indicating
which part or how many stories? If the data is properly structured, this
seems like something that could be handled in preprocessing by checking
for overlapping polygons. It looks like perhaps we might just have to
find the
>they can be brought in from another source with better documentation /
attribute tagging. (i.e. City of Toronto?)
I understand The City of Toronto Open Data License has been submitted to
the OSM Legal Working Group some time ago. The Federal Government 2.0
license and the City of Ottawa
OSM wiki: https://wiki.openstreetmap.org/wiki/Key:building:part
It's not in the import wiki though since whoever wrote it didn't know about
it at the time.
Here's what I mean by mapping 3D features in our case. Say there is a
residential tower on a podium. In the StatsCan data usually you would
Hi Yaro,
I just had a chance to look at the documentation on the source data and
I wasn't able to find anything about 3D features or parts of buildings
being mapped separately. Are you guessing here, or is there
documentation on this? If so can you point us to it?
In any case, the big
Hi,
Tangentially, I often remap areas with poor mapping and use the
replace geometry tool. I estimate it adds about 5% time to the over
all remapping effort, which is totally acceptable for the benefits of
careful redoing and saving of object history and I encourage folks to
use that way where
Hi Yaro,
Thanks for marking this as on-hold in the tasking manager. I know I came
in like a wrecking ball and I really appreciate y'all holding things up
while we discuss.
I'd be happy to validate data and help import the rest of central
Toronto once we're up and running again! I use the
Could you update the wiki to include these instructions please.
Thanks John
On Fri, 18 Jan 2019 at 14:53, Yaro Shkvorets wrote:
> John,
> >> Traditionally or the party line is if its been mapped already then to
> preserve the history you either leave it alone or manually correct it.
> Manually
Jarek,
There is no question we want this data. I went through much of it in
Toronto and Kingston and I found it to be very good, consistent and
precise. Time-wise it's somewhat current with 2016 ESRI imagery (sometimes
ahead, sometimes slightly behind) and is well-aligned with it. It offers 3D
And that is a problem with imports. Traditionally or the party line is if
its been mapped already then to preserve the history you either leave it
alone or manually correct it. Manually correcting it is very time
consuming. Often the decision is made to leave the existing way in the map.
I'm
Nate,
I'll change the project name to reflect that the import is on hold. As a
local mapper, if you want to take a lead on the Toronto import that'd be
great.
I did review some of DannyMcD's edits last night
(Mississauga-Brampton-Vaughan) and to be honest was rather disappointed
with the quality.
Some more thoughts from me.
Building outlines, particularly for single-family subdivisions as seen
in Canadian suburbs, are extremely labour-intensive to map manually.
My parents' house is now on OSM - accurately. They live in a city with
about 10,000 buildings, and about 0.5 active mappers.
Hi all,
I've just joined the talk-ca list, so please accept my apologies for not
addressing this list earlier. I'm happy to take this thread off the
imports list for now and onto talk-ca until things are ready to begin
again. The next person to reply can please feel free to remove that
email
The pilot project that took place in Ottawa for all these building imports is
what got me hooked into OSM in the first place. I would make only very minor
changes here and there. I even attempted to draw building footprints but got
burnt out after only doing a single street, which was very
As Frederik Ramm once said(sorry i'm paraphrasing from memory please don't
shoot me) There has never been a GO-Nogo for imports, you bring it up on
the mailing lists with reasonable delay, is there no objections(in this
case no one was saying anything about it for 2-3 weeks) then email the list
Along the lines of what Jarek said, sometimes silence just means tacit
acceptance, or that it's not that controversial. There's quite a bit of
government data here that is supposedly "open" but unavailable for OSM, so
I'm very glad Stats Can was able to find a way to collect municipal data
and
On Thu, 17 Jan 2019 at 21:46, OSM Volunteer stevea
wrote:
> Thanks, Jarek. Considering I am a proponent of "perfection must not be the
> enemy of good" (regarding OSM data entry), I think data which are "darn good,
> though not perfect" DO deserve to enter into OSM. Sometimes "darn good"
>
On Jan 17, 2019, at 6:27 PM, Jarek Piórkowski wrote:
> When no one is responding, sometimes it is because they are fine with
> the message as-is. I read it. I was fine with it. This isn't an
> Australian election.
I'm not sure about the allusion to Australian elections, so I'll let that pass
On Thu, 17 Jan 2019 at 21:04, OSM Volunteer stevea
wrote:
>> The import was discussed on talk-ca and in my opinion there was a consensus
>> of opinion it should go ahead. The data comes from the municipalities of
>> which there are some 37,000 separate ones in Canada. The idea of a single
>>
The thread link is:
https://lists.openstreetmap.org/pipermail/imports/2019-January/005878.html
SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
This is redirected (by request of its author) from a thread on the (talk-)
imports mailing list at .
On Jan 17, 2019, at 4:55 PM, John Whelan wrote:
> The import was discussed on talk-ca and in my opinion there was a consensus
> of opinion it should go ahead. The data comes from the
23 matches
Mail list logo
