On Nov 14, 2009, at 11:16 AM, Dave Hansen wrote:
>> What really needs to be done for TIGER addresses import is match the
>> streets from TIGER to those in OSM (which should be easy since they
>> all still have the TIGER id's) and generate the address geometry based
>> on these. Otherwise someone
So, it seems that the TIGER data have some interesting addresses like:
Non integer address: 9-35
Non integer address: 9-01
Non integer address: K200
Non integer address: K210
Anybody have any thoughts on how we should handle these? The conversion
script complains about them but I'm not even sure
On Sat, Nov 14, 2009 at 12:22 PM, Anthony wrote:
> See http://wiki.openstreetmap.org/wiki/Image:Qgis.png for an example
> of something I whipped up for my neighborhood in a few hours
http://api06.dev.openstreetmap.org/api/0.6/changeset/1825/download for
a sample of what the osm looks like.
_
Matthias Julius wrote:
>Yes, I would create a relation for each thing in the building having the
>building itself (area, node or relation) as the only member.
>
>That way the different shops (or banks, law offices, dentists, ...) in
>the building can be independant objects and reference the buildi
Dave Hansen wrote:
> If we can come up with a scheme for getting the addressing imported in a
> sane fashion and the consensus is that people want it done that way,
> it'll get imported. There are still quite a few squeaky wheels that
> like to grumble about TIGER, but I haven't heard a single pe
Matthias Julius wrote:
> I consider numbered tags to be messy. Nodes inside the building is not
> better unless you are really producing a map of the building's
> internals.
How do you figure? Strip malls typically only have one building but all
ammeneties are accessable from the outside. And
Paul Johnson wrote:
>Matthias Julius wrote:
>
>>I consider numbered tags to be messy. Nodes inside the building is not
>>better unless you are really producing a map of the building's
>>internals.
>
>How do you figure? Strip malls typically only have one building but all
>ammeneties are accessab
Paul Johnson wrote:
>Matthias Julius wrote:
>
>>I consider numbered tags to be messy. Nodes inside the building is not
>>better unless you are really producing a map of the building's
>>internals.
>
>How do you figure? Strip malls typically only have one building but all
>ammeneties are accessab
Paul Johnson wrote:
>Dave Hansen wrote:
>
>>If we can come up with a scheme for getting the addressing imported in a
>>sane fashion and the consensus is that people want it done that way,
>>it'll get imported. There are still quite a few squeaky wheels that
>>like to grumble about TIGER, but I ha
On Sun, 2009-11-15 at 10:59 -0800, Paul Johnson wrote:
> Dave Hansen wrote:
> > If we can come up with a scheme for getting the addressing imported in a
> > sane fashion and the consensus is that people want it done that way,
> > it'll get imported. There are still quite a few squeaky wheels that
Hi,
Dave Hansen wrote:
> There are still quite a few squeaky wheels that
> like to grumble about TIGER, but I haven't heard a single person say
> that it did more harm than good.
Well then you obviously haven't read the two latest entries in Matt
Amos' blog here,
http://www.asklater.com/matt/wo
On Sun, 2009-11-15 at 23:30 +0100, Frederik Ramm wrote:
> Dave Hansen wrote:
> > There are still quite a few squeaky wheels that
> > like to grumble about TIGER, but I haven't heard a single person say
> > that it did more harm than good.
>
> Well then you obviously haven't read the two latest ent
On Sun, Nov 15, 2009 at 4:20 PM, Dave Hansen wrote:
> So, what I did initially was go and contact all of the mappers in the US
> that I could find. I asked them all individually what should be done in
> their local areas and I believe I was able to follow their wishes
> without failure.
Are you
Hi Dave,
I'll bud in for a moment :) .. with my 2 Canadian pennies
On Sun, Nov 15, 2009 at 1:20 PM, Dave Hansen wrote:
> On Sun, 2009-11-15 at 10:59 -0800, Paul Johnson wrote:
> > Dave Hansen wrote:
> > > If we can come up with a scheme for getting the addressing imported in
> a
> > > sane fash
On Sun, 2009-11-15 at 17:23 -0500, Anthony wrote:
> On Sun, Nov 15, 2009 at 4:20 PM, Dave Hansen wrote:
> > So, what I did initially was go and contact all of the mappers in the US
> > that I could find. I asked them all individually what should be done in
> > their local areas and I believe I wa
On Sun, 2009-11-15 at 14:25 -0800, Sam Vekemans wrote:
> 1 - A few people (we can call the data conversion team) are in charge
> of taking the data in it's source form (in this case SHP) We use the
> tools availble (shp-to-osm.jar and/or shp2osm.py) and are the ones who
> create a set of 'rules' li
On Sun, 2009-11-15 at 14:33 -0800, Dave Hansen wrote:
> Yeah, and that does sound like a really nice way to do it, especially
> when there is existing data.
Anybody want to be on the USA "conversion team"? :)
-- Dave
___
Talk-us mailing list
Talk-us
On Sun, Nov 15, 2009 at 5:36 PM, Dave Hansen wrote:
> On Sun, 2009-11-15 at 14:33 -0800, Dave Hansen wrote:
>> Yeah, and that does sound like a really nice way to do it, especially
>> when there is existing data.
>
> Anybody want to be on the USA "conversion team"? :)
Absolutely.
___
On Sun, 2009-11-15 at 14:49 -0800, Dan Putler wrote:
> The
> upshot, for a number of US counties you would rather use the county
> centerline road data rather than TIGER data as the basis of the
> import.
That's really good news.
This is exactly what happened for Massachusetts. They had better d
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
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
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: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
Paul Johnson writes:
> The TIGER import should never have been done.
If the data is THAT bad where you live, then delete it. But where I
live, TIGER is great, so please talk for yourself.
--
--my blog is athttp://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley
On Sun, 2009-11-15 at 18:34 -0500, Russ Nelson wrote:
> Paul Johnson writes:
> > The TIGER import should never have been done.
>
> If the data is THAT bad where you live, then delete it. But where I
> live, TIGER is great, so please talk for yourself.
The funniest thing is that Paul and I live
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
I updated my whole-US map for Garmin devices. It's stolen from the
Cloudmade state gmapsupp images that you can find here:
http://downloads.cloudmade.com/north_america/united_states/
and pieced together with mkgmap and wget. Just take the gmapsupp.img
file from here:
http://dav
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
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
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, 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
On Sun, Nov 15, 2009 at 6:45 PM, Dave Hansen wrote:
> I updated my whole-US map for Garmin devices.
> Just take the gmapsupp.img
> file from here:
>
> http://daveh.dev.openstreetmap.org/garmin/
>
> and put in the /garmin/ directory on your device (if you have an SD card
> unit).
Thanks fo
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
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
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
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: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
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
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, 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
Alan Millar wrote:
no one is interested to cleanup crap after a bad import.
I am.
tiger import was great from technical
point of view but didn't allow to build a community from scratch.
I didn't want to build anything from scratch. I'm simply not t
Yeah, and that does sound like a really nice way to do it, especially
when there is existing data.
Anybody want to be on the USA "conversion team"? :)
sure, post all your ideas and improvements. if the noise is too high we can create another list f
On 11/15/09 6:45 PM, Dave Hansen wrote:
> and put in the /garmin/ directory on your device (if you have an SD card
> unit). I'll be updating these periodically as I feel the need. I think
> I also have my methods down to a point where I could just script it and
> make these weekly or something, i
On 11/15/09 9:17 PM, Richard Welty wrote:
> On 11/15/09 6:45 PM, Dave Hansen wrote:
>
>> and put in the /garmin/ directory on your device (if you have an SD card
>> unit). I'll be updating these periodically as I feel the need. I think
>> I also have my methods down to a point where I could j
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
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...
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 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: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
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
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
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
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
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
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, 2009-11-15 at 21:17 -0500, Richard Welty wrote:
> On 11/15/09 6:45 PM, Dave Hansen wrote:
> > and put in the /garmin/ directory on your device (if you have an SD card
> > unit). I'll be updating these periodically as I feel the need. I think
> > I also have my methods down to a point wher
57 matches
Mail list logo
