http://www.openstreetmap.org/?lat=42.908002lon=-78.91749zoom=18layers=M
One example of what not to do :)
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
On 11/2/11 1:49 AM, Nathan Mills wrote:
On Wed, 02 Nov 2011 00:02:13 -0400, Richard Welty wrote:
i don't know about that, but i certainly think that the current default
mapnik rendering for openstreetmap.org is showing us too much addressing
detail. i'm not sure what showing the address
On Wed, Nov 2, 2011 at 12:02 AM, Richard Welty rwe...@averillpark.net wrote:
On 11/1/11 11:50 PM, Martijn van Exel wrote:
Is there a way for mapnik to only render features of a certain class
if there's not more than a certain density of them?
i don't know about that, but i certainly think
On Wed, Nov 2, 2011 at 9:35 AM, Steven Johnson sejohns...@gmail.com wrote:
Up to now, we've been talking largely about addresses as point features.
However, one thing I think would be good to have is block ranges on streets.
What I mean is a tag that indicates this is the 1000 block, the 1100
Steven Johnson sejohns...@gmail.com wrote:
Up to now, we've been talking largely about addresses as point
features.
However, one thing I think would be good to have is block ranges on
streets. What I mean is a tag that indicates this is the 1000 block,
the
1100 block, the 1200 block, etc.
On Wed, Nov 2, 2011 at 9:35 AM, Steven Johnson sejohns...@gmail.com wrote:
Up to now, we've been talking largely about addresses as point features.
However, one thing I think would be good to have is block ranges on streets.
That would require breaking a way at each junction, wouldn't it? Some
On Wed, Nov 2, 2011 at 7:35 AM, Steven Johnson sejohns...@gmail.com wrote:
Up to now, we've been talking largely about addresses as point features.
However, one thing I think would be good to have is block ranges on streets.
What I mean is a tag that indicates this is the 1000 block, the 1100
On Wed, Nov 2, 2011 at 10:17 AM, Martijn van Exel m...@rtijn.org wrote:
On Wed, Nov 2, 2011 at 7:35 AM, Steven Johnson sejohns...@gmail.com
wrote:
Up to now, we've been talking largely about addresses as point features.
However, one thing I think would be good to have is block ranges on
On Wed, Nov 2, 2011 at 11:24 AM, Ian Dees ian.d...@gmail.com wrote:
Address range information can be derived from existing TIGER data quite
simply.
I'm not sure how simple it is. It's simple in cases where TIGER data
matches up very closely with OSM data. But that isn't universally
true. And
Ian,
On Wed, Nov 2, 2011 at 9:24 AM, Ian Dees ian.d...@gmail.com wrote:
[..]
Address range information can be derived from existing TIGER data quite
simply.
However, I would argue that we should only talk about importing point
information for two reasons:
1) address ranges get in the way
On Wed, Nov 2, 2011 at 11:14 AM, Anthony o...@inbox.org wrote:
On Wed, Nov 2, 2011 at 11:24 AM, Ian Dees ian.d...@gmail.com wrote:
Address range information can be derived from existing TIGER data quite
simply.
I'm not sure how simple it is. It's simple in cases where TIGER data
matches
On Wed, Nov 2, 2011 at 10:38 AM, John F. Eldredge j...@jfeldredge.com wrote:
This idea, of tagging address ranges within blocks, sounds like a good idea
to me. Some cities, such as Louisville, KY, put address ranges on street
signs, which would make gathering such information easy in those
Anthony,
On Wed, Nov 2, 2011 at 10:14 AM, Anthony o...@inbox.org wrote:
On Wed, Nov 2, 2011 at 11:24 AM, Ian Dees ian.d...@gmail.com wrote:
Address range information can be derived from existing TIGER data quite
simply.
I'm not sure how simple it is. It's simple in cases where TIGER data
On Wed, Nov 2, 2011 at 11:17 AM, Martijn van Exel m...@rtijn.org wrote:
Ian,
On Wed, Nov 2, 2011 at 9:24 AM, Ian Dees ian.d...@gmail.com wrote:
[..]
Address range information can be derived from existing TIGER data quite
simply.
However, I would argue that we should only talk about
On Wed, Nov 2, 2011 at 12:19 PM, Martijn van Exel m...@rtijn.org wrote:
I'm all for not importing data where there's existing data people can
use, but in the case of TIGER addresses you could actually make a
point for importing: OSM could be a platform for improving that
address data (like it
On Wed, Nov 2, 2011 at 11:23 AM, Anthony o...@inbox.org wrote:
On Wed, Nov 2, 2011 at 12:19 PM, Martijn van Exel m...@rtijn.org wrote:
I'm all for not importing data where there's existing data people can
use, but in the case of TIGER addresses you could actually make a
point for
Anthony
On Wed, Nov 2, 2011 at 10:23 AM, Anthony o...@inbox.org wrote:
On Wed, Nov 2, 2011 at 12:19 PM, Martijn van Exel m...@rtijn.org wrote:
I'm all for not importing data where there's existing data people can
use, but in the case of TIGER addresses you could actually make a
point for
On Wed, Nov 2, 2011 at 11:14 AM, Anthony o...@inbox.org wrote:
Which brings me to the conclusion that there's no point in importing
TIGER address information. A geocoder can simply try to find the
address in OSM, and fall back to TIGER if the address isn't in OSM.
Then, once the lat/lon is
On Wed, Nov 2, 2011 at 1:17 PM, Toby Murray toby.mur...@gmail.com wrote:
On Wed, Nov 2, 2011 at 11:14 AM, Anthony o...@inbox.org wrote:
Which brings me to the conclusion that there's no point in importing
TIGER address information. A geocoder can simply try to find the
address in OSM, and
On Wed, Nov 2, 2011 at 3:17 PM, Toby Murray toby.mur...@gmail.com wrote:
On Wed, Nov 2, 2011 at 11:14 AM, Anthony o...@inbox.org wrote:
Which brings me to the conclusion that there's no point in importing
TIGER address information. A geocoder can simply try to find the
address in OSM, and
Folks,
Do you realize:
1. We already have a method for address interpolation. It's called
addr:interpolation
There's no need for new tags.
2. Cutting ways into blocks would make for bedlam. There are better
ways, but they require a bit more work. If this is something people
want to take out of
Serge, I think the topic of the thread is improving addresses through
imports, not how we should tag addresses (not that you're derailing it, but
I don't want to go too far afield).
It seems like we have a general agreement that manually merging in pieces
of address data converted to OSM format
On Wed, 2 Nov 2011 09:35:58 -0400, Steven Johnson wrote:
Up to now, weve been talking largely about addresses as point
features. However, one thing I think would be good to have is block
ranges on streets. What I mean is a tag that indicates this is the
1000 block, the 1100 block, the 1200
I'd be interested in a way of auto-tagging blocks in a grid like most
newer cities have. Set the zero point and intermediate points and it
interpolates for you.
___
Talk-us mailing list
Talk-us@openstreetmap.org
Hi,
On Tue, 1 Nov 2011 17:14:03 -0600
Martijn van Exel m...@rtijn.org wrote:
But let's discuss: are
address imports useful (I say yes, for geocoding and routing they're
indispensable), necessary (I say yes, potential OSM data users will
want to be able to do these things) and feasible (I say
On Wed, 2 Nov 2011 23:12:09 +0100, Frederik Ramm wrote:
Importing more and more data will not make OSM strong. It might make
OSM look useful in the short term but that's cheap usefulness
So you're saying that if I don't go out and spend thousands of dollars
and countless hours driving every
Hi Frederik,
On Wed, Nov 2, 2011 at 5:12 PM, Frederik Ramm frede...@remote.org wrote:
Hi,
On Tue, 1 Nov 2011 17:14:03 -0600
Martijn van Exel m...@rtijn.org wrote:
But let's discuss: are
address imports useful (I say yes, for geocoding and routing they're
indispensable), necessary (I
Frederik,
On Wed, Nov 2, 2011 at 4:12 PM, Frederik Ramm frede...@remote.org wrote:
Hi,
On Tue, 1 Nov 2011 17:14:03 -0600
Martijn van Exel m...@rtijn.org wrote:
But let's discuss: are
address imports useful (I say yes, for geocoding and routing they're
indispensable), necessary (I say yes,
On 11/2/11 6:52 PM, Martijn van Exel wrote:
It's hardly a quick fix and you know that's not what we are setting
out to achieve here. A quick fix would be for me to just take those
shapefiles and dump them right into OSM. What we're doing instead here
is considering if and how existing sources
On 11/2/2011 6:59 PM, Richard Welty wrote:
for what it's worth, i think Martijn is on precisely the right path here.
imports go wrong when they're done carelessly and without any quality
control. it doesn't have to be that way.
I'm not against importing high quality address data, but can see
On Wed, Nov 2, 2011 at 4:26 PM, Serge Wroclawski emac...@gmail.com wrote:
Folks,
Do you realize:
1. We already have a method for address interpolation. It's called
addr:interpolation
There's no need for new tags.
Yes. In fact, I mentioned it above along with a link
On 11/2/2011 9:46 PM, Anthony wrote:
2. Cutting ways into blocks would make for bedlam.
Why?
If there's no difference between the blocks except for addressing, it
adds a needless extra step to map corrections. Instead of selecting an
entire street with a single click to correct the
On Wed, Nov 2, 2011 at 6:44 PM, Ian Dees ian.d...@gmail.com wrote:
I think it's reasonable to take a small bite out of that huge task by using
data that was previously crowdsourced (via taxpayer money) and ask as many
members of the current OSM community in the US to manually add the data and
On Wed, Nov 2, 2011 at 9:59 PM, Anthony o...@inbox.org wrote:
On Wed, Nov 2, 2011 at 9:55 PM, Mike N nice...@att.net wrote:
On 11/2/2011 9:46 PM, Anthony wrote:
2. Cutting ways into blocks would make for bedlam.
Why?
If there's no difference between the blocks except for addressing, it
On 11/2/2011 9:59 PM, Anthony wrote:
I guess, but there are already so many reasons to split ways that I
think you're fighting a losing battle. A better solution would be to
adopt something like street relations, so that the name of a road
isn't duplicated on every single way in the first
From: Mike N [mailto:nice...@att.net]
Subject: Re: [Talk-us] Address improvement through imports?
Splitting ways for maxSpeed, public transport, cycle lanes, route
relations, and lane counts are all value-added mapper observations, but
still often conveniently span a number of blocks.
On Wed, Nov 2, 2011 at 9:59 PM, Anthony o...@inbox.org wrote:
I guess, but there are already so many reasons to split ways that I
think you're fighting a losing battle. A better solution would be to
adopt something like street relations, so that the name of a road
isn't duplicated on every
On Nov 2, 2011, at 9:28 AM, Martijn van Exel wrote:
On Wed, Nov 2, 2011 at 10:23 AM, Anthony o...@inbox.org wrote:
On Wed, Nov 2, 2011 at 12:19 PM, Martijn van Exel m...@rtijn.org wrote:
I'm all for not importing data where there's existing data people can
use, but in the case of TIGER
On Wed, Nov 2, 2011 at 5:12 PM, Frederik Ramm frede...@remote.org wrote:
Hi,
On Tue, 1 Nov 2011 17:14:03 -0600
Martijn van Exel m...@rtijn.org wrote:
But let's discuss: are
address imports useful (I say yes, for geocoding and routing they're
indispensable), necessary (I say yes, potential
39 matches
Mail list logo
