On Mon, Nov 16, 2009 at 12:07 PM, SteveC wrote:
>
> On Nov 15, 2009, at 8:23 PM, Anthony wrote:
>
>> On Sun, Nov 15, 2009 at 10:05 PM, SteveC wrote:
>>> So you put the house numbers on the nodes and then what happens with them
>>> all when you switch the way
>>> direction?
>>
>> Nothing.
>>
>>>
On Nov 15, 2009, at 8:23 PM, Anthony wrote:
> On Sun, Nov 15, 2009 at 10:05 PM, SteveC wrote:
>> So you put the house numbers on the nodes and then what happens with them
>> all when you switch the way
>> direction?
>
> Nothing.
>
>> Every editor has to know to reorder the left and right hand
On 16 Nov 2009, at 7:40 , Anthony wrote:
> On Mon, Nov 16, 2009 at 9:41 AM, Lord-Castillo, Brett
> wrote:
>> I'm still getting a handle on the schemas in use for OSM, and noticed that
>> concept of matching address nodes to ways when doing imports.
>> I'm not so sure this will be very functiona
On Mon, Nov 16, 2009 at 9:41 AM, Lord-Castillo, Brett
wrote:
> I'm still getting a handle on the schemas in use for OSM, and noticed that
> concept of matching address nodes to ways when doing imports.
> I'm not so sure this will be very functional for floodplain counties or heavy
> agricultural
I'm still getting a handle on the schemas in use for OSM, and noticed that
concept of matching address nodes to ways when doing imports.
I'm not so sure this will be very functional for floodplain counties or heavy
agricultural counties. We have thousands of addresses with no corresponding
roads
On Sun, Nov 15, 2009 at 10:23 PM, Anthony wrote:
> On Sun, Nov 15, 2009 at 10:05 PM, SteveC wrote:
>> So you put the house numbers on the nodes and then what happens with them
>> all when you switch the way
>> direction?
>
> Nothing.
http://www.openstreetmap.org/?lat=28.051148&lon=-82.552442&zo
On Sun, Nov 15, 2009 at 10:05 PM, SteveC wrote:
> So you put the house numbers on the nodes and then what happens with them all
> when you switch the way
> direction?
Nothing.
> Every editor has to know to reorder the left and right hand numbers?
Nope. Up/Forward is defined as the direction i
Well at least in theory, TIGER 2009 is positionally much more
accurate. Theory. I reserve judgement either way.
Peter Batty writes:
> Russ, I think you misunderstood my comment. I am in the "TIGER import is a
> good thing" camp. But in the areas I have worked in it has needed a fair bit
> of
Russ, I think you misunderstood my comment. I am in the "TIGER import is a
good thing" camp. But in the areas I have worked in it has needed a fair bit
of minor positional cleanup. My point is that in those cases where you need
to graphically adjust a street, I don't want to have to edit three or m
Anthony writes:
> On Sun, Nov 15, 2009 at 7:24 PM, Peter Batty wrote:
> > I'm coming a bit late to this debate, but I just wanted to raise
> > a fairly basic question, which is whether the Karlsruhe schema is
> > the best one to use in the situation we find ourselves in with
> > TIGER, where
On Nov 15, 2009, at 8:03 PM, Anthony wrote:
> On Sun, Nov 15, 2009 at 9:58 PM, Peter Batty wrote:
>> I think the Karlsruhe schema is good where you are trying to model addresses
>> pretty precisely and you're not expecting major updates to the street
>> network. But I think with the TIGER data w
On Sun, Nov 15, 2009 at 9:58 PM, Peter Batty wrote:
> I think the Karlsruhe schema is good where you are trying to model addresses
> pretty precisely and you're not expecting major updates to the street
> network. But I think with the TIGER data we have a different situation. And
> like I said, th
I think the Karlsruhe schema is good where you are trying to model addresses
pretty precisely and you're not expecting major updates to the street
network. But I think with the TIGER data we have a different situation. And
like I said, the two aren't incompatible, you can use a simpler approach on
On Sun, Nov 15, 2009 at 9:22 PM, Peter Batty wrote:
> When I said "messy", I guess I was thinking of two things - one is doing the
> import, as you mention here (which is sort of where the discussion started).
> This seems quite a bit more complex if you have to split ways and insert
> nodes.
You
I suspect the Karlsruhe schema is a bit like the license change. Everyone
thinks they have a better idea, and it will take 3 weeks of back and forth to
go over it before they figure out that it's the best (or, least worst) way
forward... but by then another 3 people who need convincing pop up...
When I said "messy", I guess I was thinking of two things - one is doing the
import, as you mention here (which is sort of where the discussion started).
This seems quite a bit more complex if you have to split ways and insert
nodes.
The other is in writing a geocoding engine based on the data whi
On Sun, Nov 15, 2009 at 8:32 PM, Peter Batty wrote:
> If you have two streets intersecting and put a number on that node, it isn't
> clear which street that applies to. You could add an artificial node close
> to the end of the street, but that seems a bit more messy to me.
If you're adding the n
If you have two streets intersecting and put a number on that node, it isn't
clear which street that applies to. You could add an artificial node close
to the end of the street, but that seems a bit more messy to me. So my gut
feel is that the simplest approach is still attributes on the street.
Y
On Sun, 2009-11-15 at 18:02 -0700, Peter Batty wrote:
> I would be interested in being on the USA conversion team - how do I
> sign up? (I am in Denver incidentally
Perhaps someone should set up a wiki page of interested parties. We
also need to start recording some of the consensus that's coming
On Sun, Nov 15, 2009 at 7:47 PM, Dale Puch wrote:
> Split each intersection, then build relations for the streets.
Do you even have to split? Just add a node, and put the house number
on the node.
> One of the problems has been which side is left if the way is reversed.
Put the house number on
I would be interested in being on the USA conversion team - how do I sign
up? (I am in Denver incidentally)
On Sun, Nov 15, 2009 at 5:52 PM, Anthony wrote:
> On Sun, Nov 15, 2009 at 7:24 PM, Peter Batty
> wrote:
> > I'm coming a bit late to this debate, but I just wanted to raise a fairly
> > b
On Sun, Nov 15, 2009 at 7:24 PM, Peter Batty wrote:
> I'm coming a bit late to this debate, but I just wanted to raise a fairly
> basic question, which is whether the Karlsruhe schema is the best one to use
> in the situation we find ourselves in with TIGER, where quite a bit of data
> cleanup is
Oops hit reply instead of replying to the mailing list :/
I personally favor having the possible address range in the street way
segment (between intersections) Easier to edit and maintain, as well as
smaller memory and bandwidth when working with it. Split each intersection,
then build relation
For a single county or jurisdiction, if you delete the TIGER data and
import more accurate local data, what do you do at the boundaries?
County/Stare data sets I've seen usually get cut off +/- a few hundred
feet (if that) from the boundary. Does somebody go through and make
them fit/connect
Hi all,
I'm coming a bit late to this debate, but I just wanted to raise a fairly
basic question, which is whether the Karlsruhe schema is the best one to use
in the situation we find ourselves in with TIGER, where quite a bit of data
cleanup is anticipated. The major concern I have is that if you
On Sun, Nov 15, 2009 at 7:04 PM, Dave Hansen wrote:
> There's nothing wrong with doing point-level address imports. The only
> thing I would suggest is ensuring that we connect those points ways or
> whatever to the roads that represent them somehow.
1) Why?
2) Are you planning on doing that wi
Dan,
Alexandria gave us permission to import their data but still wanted
the 100 dollar CD fee. Someone paid that and we do have the data.
As far as I know nobody has asked Fairfax County, but I figured making
D.C. look nice with a combination of mapping and importing would be a
strong tool
On Sun, 2009-11-15 at 18:54 -0500, Anthony wrote:
> On Sun, Nov 15, 2009 at 6:17 PM, Dave Hansen wrote:
> > On Sun, 2009-11-15 at 18:11 -0500, Kate Chapman wrote:
> >> What's wrong with doing automated addressing imports in situations
> >> where we have point level address data?
> >
> > The issue
On Sun, Nov 15, 2009 at 6:17 PM, Dave Hansen wrote:
> On Sun, 2009-11-15 at 18:11 -0500, Kate Chapman wrote:
>> What's wrong with doing automated addressing imports in situations
>> where we have point level address data?
>
> The issue is that it may not line up with the roads at all.
Well, addre
Hi Dan,
Both manual and donated data. I've been addressing my neighborhood in
Virginia but Washington D.C. donated point level addresses.
Kate Chapman
On Nov 15, 2009, at 6:37 PM, Dan Putler
wrote:
> Hi Kate,
>
> How have the address points been obtained? From OSM users? The Census
> Bure
On Sun, 2009-11-15 at 18:28 -0500, Kate Chapman wrote:
> Maybe I'm confused about the address versus road information. I would
> think the address point would be the front door of the building and
> would not be a relation to the road. So the node of the address and
> the way of the road would no
Dave,
Understood, I would envision it being a partially manual and partially
automated process.
Maybe I'm confused about the address versus road information. I would think
the address point would be the front door of the building and would not be a
relation to the road. So the node of the addre
On Sun, 2009-11-15 at 18:11 -0500, Kate Chapman wrote:
> What's wrong with doing automated addressing imports in situations
> where we have point level address data?
The issue is that it may not line up with the roads at all. We also
need to ensure that we *find* the roads to which it refers to e
Dan,
What's wrong with doing automated addressing imports in situations where we
have point level address data? Or are you just referring to not importing
the addressing that is available for the Tiger data?
Kate Chapman
On Sun, Nov 15, 2009 at 6:00 PM, Dave Hansen wrote:
> On Sun, 2009-11-1
34 matches
Mail list logo
