[Talk-us] holes in Columbus OH?

[Peter Dobratz]

I currently have the opportunity to do some mapping in Columbus, Ohio.
 The admin boundary for the city seems a bit odd:

http://www.openstreetmap.org/browse/relation/182706

There seem to be a lot of holes in the multipolygon relation, and it
seems strange to me that there are so many places within the city that
are not part of the city.  Is anyone more familiar with this area that
give an explanation for this?

I'm focusing on adding some POIs and correcting streets, but it would
be nice to have the city limits cleaned up at some point.

--Peter

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Seeing things you don't care about in the database

[andrzej zaborowski]

> On Mon, Jun 11, 2012 at 4:47 PM, Nathan Edgars II 
> wrote:
>> I agree with this. But I'm not sure that there is a solution. You can use
>> XAPI/Overpass API to download only roads in an area, but you get conflicts
>> (or worse, you move a node and screw up something else without realizing it)
>> when nodes are shared with other non-downloaded features. This can happen
>> directly (road passing through a building or the IMO bad practice of using
>> roads as landuse borders) or indirectly (e.g. road - parking lot - building
>> - landuse).

One option would be for every object returned from an API query to
have a complete/incomplete flag.  This flag would be set if an object
(e.g. a node) is part of another object that has not been downloaded
because it's not on the same "layer".  If the editor sees such an
object being modified, it pulls all the "parent" elements from the
API.

Cheers

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Seeing things you don't care about in the database

[the Old Topo Depot]

>From a slightly different perspective, there are, in fact, many solutions,
each of which may be suboptimal in some respects.  In any case, the
scalability issues arising as a result of data growth will need to be dealt
with.

Some benefits may be had looking for optimizations to apply to data
download implementation, which would allow increasing the download sizes
for JOSM.  I use the web based editors for very simple/very small areas as
they're significantly slower than JOSM.

It is certainly possible to split feature storage into separate layers, but
it would make conflict checking and conflation (much) more complex, and
ideally would be shared nothing across the layers.  Still, at some point, a
data partitioning scheme may be required as size continues to increase.

If editing with JOSM, subsets of features can be turned off for display
purposes to help focus on the current task, but all data still needs to be
loaded locally, so not very helpful in densely featured areas.

On Mon, Jun 11, 2012 at 4:47 PM, Nathan Edgars II wrote:

> On 6/11/2012 7:17 PM, Mark Gray wrote:
>
>> On one hand, I share the frustration of having lots of new data in
>> an area making some of our tools slower and more difficult to use.
>> In my area a building footprint import slowed down most of the
>> mapping tools and land use polygons can get in the way of editing
>> roads.
>>
>
> I agree with this. But I'm not sure that there is a solution. You can use
> XAPI/Overpass API to download only roads in an area, but you get conflicts
> (or worse, you move a node and screw up something else without realizing
> it) when nodes are shared with other non-downloaded features. This can
> happen directly (road passing through a building or the IMO bad practice of
> using roads as landuse borders) or indirectly (e.g. road - parking lot -
> building - landuse).
>
>
> __**_
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-us
>



-- 
John Novak
585-OLD-TOPOS (585-653-8676)
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Seeing things you don't care about in the database

[Nathan Edgars II]

On 6/11/2012 7:17 PM, Mark Gray wrote:

On one hand, I share the frustration of having lots of new data in
an area making some of our tools slower and more difficult to use.
In my area a building footprint import slowed down most of the
mapping tools and land use polygons can get in the way of editing
roads.


I agree with this. But I'm not sure that there is a solution. You can 
use XAPI/Overpass API to download only roads in an area, but you get 
conflicts (or worse, you move a node and screw up something else without 
realizing it) when nodes are shared with other non-downloaded features. 
This can happen directly (road passing through a building or the IMO bad 
practice of using roads as landuse borders) or indirectly (e.g. road - 
parking lot - building - landuse).


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Seeing things you don't care about in the database

[Mark Gray]

On one hand, I share the frustration of having lots of new data in
an area making some of our tools slower and more difficult to use.
In my area a building footprint import slowed down most of the
mapping tools and land use polygons can get in the way of editing
roads.

On the other hand, I really like that the map looks a lot better
at close zooms with building footprints and at some zooms with
land use even if neither layer is perfect. This is not just about
looks: it is also much better for being sure you are oriented when
you are out there and can see the buildings on the map line up
with real buildings. Address and POI information looks much better
with the context of the buildings they are associated with.

I think that one of the strengths of OSM is that people can map
what they are interested in, whether it is roads or railways or
hiking trails or power lines or bike racks or local businesses.
OSM is definitely getting beyond "just streets" in many places and
I think that is a good thing to be encouraged and celebrated.

If you want to just edit some streets, though, you should not have
to download and render every object in the area and have them all
active as things you might want to make a junction with.

I think the answer is to improve our tools so things we don't care
about right now don't get in the way.

The renderers include powerful tools for filtering what should be
rendered for a particular purpose, can't we use some similar
smarts in editors to let people choose:
1. what they are editing
2. what they still want to see but only as inactive background

If I invested in getting JOSM working again and learned all its
tricks could I do this today? Lately I have just been using
Potlatch 2. It is so easy to navigate to the place I want to work
on the rendered map, switch to edit mode, edit, scroll to the
east, edit, save, done. When I used JOSM I missed the simplicity
of the Potlatch work flow so much, but I might be willing to try
again.

-- 
Mark Gray

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Contact info for Ben Supnik

[the Old Topo Depot]

if anyone has it, would be apprecaited.  Or, Ben, if you're out there,
please contact me offlist re NHD shapefiles.

Thanks in Advance

-- 
John Novak
585-OLD-TOPOS (585-653-8676)
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Import discussions

[the Old Topo Depot]

The OSM UK wiki has a priorities page (
http://wiki.openstreetmap.org/wiki/UK_Mapping_Priorities); since a
similarly named page does not exist for the US (
http://wiki.openstreetmap.org/wiki/US_Mapping_Priorities), we should create
one and begin populating it.

Best,

On Mon, Jun 11, 2012 at 8:15 AM, Mike N  wrote:

> On 6/11/2012 10:54 AM, Alan Mintz wrote:
>
>> Personally, I wish that all those that want to import building outlines
>> would first think about the existing street network (this, after all,
>> being OpenSTREETMap). So much of the US is still unedited TIGER 2005
>> data - mis-aligned, poorly connected, stale-named, and missing lots of
>> new construction from the peak to the end of the housing boom.
>>
>
> I'll agree with this.   I'm not sure of the value of building outlines
> until someone actively uses or updates them.
>
> __**_
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-us
>



-- 
John Novak
585-OLD-TOPOS (585-653-8676)
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] User adding hidden and non-official Interstate ref tags

[James Mast]

I've just notice that the user "SD Mapman" has added in the ref tags several 
hidden Interstates and removed what was originally in those tags (example: 
ref=US 27 > ref=I 124).  It seems he's done this for all of the hidden 
Interstates.http://www.openstreetmap.org/user/SD%20Mapman/edits?page=5 He's 
also added I-49 ref tags in MO, even though the Interstate there isn't official 
yet till later this year.  (should be on page 1 and page 2 of his edits atm) He 
also added the I-74 tags back to the Laurinburg, NC bypass of US-74.  I haven't 
heard anything about NCDOT getting permission to put the shields back up yet on 
that segment (I personally was lucky enough to travel that section while the 
shields were still up). I've sent him a message on this subject already and 
gave him a link to talk-us.  Hopefully, he'll come on here and talk about his 
edits on this subject. In the meantime, who here wants to play fix the ref 
tags? lol. --James   ___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Import discussions

[Mike N]

On 6/11/2012 10:54 AM, Alan Mintz wrote:

Personally, I wish that all those that want to import building outlines
would first think about the existing street network (this, after all,
being OpenSTREETMap). So much of the US is still unedited TIGER 2005
data - mis-aligned, poorly connected, stale-named, and missing lots of
new construction from the peak to the end of the housing boom.


I'll agree with this.   I'm not sure of the value of building outlines 
until someone actively uses or updates them.


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Import discussions

[Alan Mintz]

There have been several threads about import guidelines and building 
imports lately. Still, nobody is ever concerned with the data size and 
performance issues that will surely be caused by expanded imports of 
building and lot outlines (as discussed recently for Bakersfield, 
California). Shouldn't we have a plan to deal with this before it becomes a 
bigger problem?


Personally, I wish that all those that want to import building outlines 
would first think about the existing street network (this, after all, being 
OpenSTREETMap). So much of the US is still unedited TIGER 2005 data - 
mis-aligned, poorly connected, stale-named, and missing lots of new 
construction from the peak to the end of the housing boom.


Shouldn't we endeavor to make the street network accurate before anything 
else? That's the only way to get people to actually use the map and then, 
hopefully, contribute to it. I've done years of editing in southern 
California and still have to use Bing or Google Maps when I go someplace I 
(or one of the other handful of mappers in this huge area) haven't mapped, 
just for reliability.


--
Alan Mintz 


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us