Hi
Problems 1, 2, 3, 4, 6, and 9 should have been fixed before the first
file was uploaded. OSM files that are going to be imported, should
100% clean in the JOSM validator. This is a pretty basic thing, right?
7 - Building that already exist in OSM should be skipped, especially
since it looks li
Ok, here's what I think we should do:
1. Join T intersections in conversion (Matt and I are on this)
https://github.com/osmlab/nycbuildings/issues/8
2. Set up a QA script reporting common mistakes (start here
https://github.com/osmlab/nycbuildings/issues/18)
3. Write up nice blog post highlighting
> From: Frederik Ramm [mailto:frede...@remote.org]
> Sent: Monday, October 14, 2013 12:55 PM
> Subject: [Imports] kartverket imports to OpenStreetMap
>
> Dear k...@nuug.no readers,
> (Cc to imports@openstreetmap.org)
>
>I am writing to you in my role as a member of the OSMF Data Working
> Gro
2013/10/14 Alex Barth
> (This is BCC to tagg...@osm.org, conversation to happen on
> imports@openstreetmap.org.)
>
> At the NYC building and address import we're facing the following question:
>
> **In cases where there is one address point per building, should we merge
> the address information
On Mon, Oct 14, 2013 at 9:51 PM, Serge Wroclawski wrote:
> Yet, despite all this instruction, we had a lot of errors in the data,
> even from extremely experienced mappers.
> We could really use your help in coming up with solutions to these problems!
We have the same issues in the French buildi
Dear k...@nuug.no readers,
(Cc to imports@openstreetmap.org)
I am writing to you in my role as a member of the OSMF Data Working
Group. Our job is to watch out for vandalism, mapping disputes,
copyright violations, and problematic imports.
It is the last of these that I'm writing to you about.
Hi all,
As Alex mentioned, we had a test of our import this weekend.
The event went great, with 22 people coming to help import.
Before the event began, Alex gave a great walkthrough. In addition, we
had written instructions on the tasking manager:
http://tasks.openstreetmap.us/job/2
And I mad
Hi,
> ## Option 2: Always keep address points separate
My $.02c -
* address on house outline - common
* address on a node when no houe outline exists - common
* address on a node that is part of the house outline - frequently used
when people want to be able to locate the entrance
* address o
On 10/14/2013 12:35 PM, Alex Barth wrote:
## Option 2: Always keep address points separate
I think this makes sense - I have gravitated in this direction with
larger buildings; place a separate node (or reuse a building outline
node) at the entrance most likely to be used by visitors; GPS na
On Mon, Oct 14, 2013 at 9:35 AM, Alex Barth wrote:
> ## Option 2: Always keep address points separate
>
> In this case we never merge addresses to building polygons, instead always
> keep them as separate entities.
>
> Pros:
>
> a) this is the NYC GIS way, making it nicer for GIS folks to use OSM
I like keeping the address separate, since NYC GIS put in the work to give
the spatial locations of the addresses a meaning other than just the
centroid.
Here seems to be an example of where the imports have begun:
http://www.openstreetmap.org/#map=18/40.64105/-73.96687
On Mon, Oct 14, 2013 at 1
There's a bit of context missing from this conversation, so I want to
fill people in on what happened, and then we can discuss the technical
merits.
Alex made his proposal (with my endorsement) before the import
happened. Alex suggestebut then modified the data to this alternate
way before the imp
I would tend to agree with you to keep address nodes separate from
buildings. It makes mapping POI easier, makes geocoders more accurate, and
is generally easier to work with as a dataset.
On Mon, Oct 14, 2013 at 11:35 AM, Alex Barth wrote:
> (This is BCC to tagg...@osm.org, conversation to happ
(This is BCC to tagg...@osm.org, conversation to happen on
imports@openstreetmap.org.)
At the NYC building and address import we're facing the following question:
**In cases where there is one address point per building, should we merge
the address information onto the building polygon and toss t
14 matches
Mail list logo
