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
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
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
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
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-ca m
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 Fri, 2009-03-27 at 12:10 -0300, William Lachance wrote:
> I see the argument of not wanting to blow away people's hard work, but
> from my (admittedly NS-centric view), that approach will lead to severe
> limitations in terms of the quality and consistency of the results.
The great thing about
On Fri, 2008-12-19 at 03:15 -0800, Sam Vekemans wrote:
> Where one option is to use an OpenLayers slippy map, where users could
> use a rendered version of all the Tiger data, and trace with it, just
> as they would with the Yahoo imagery layer?
I'd really rather just import the data rather than b
On Wed, 2008-12-17 at 00:26 -0800, Dan Putler wrote:
> One way has the TIGER TLID attribute, the other way does not (the person
> doing the editing of the way missing the TLID probably didn't understand
> the relevance of it, and didn't think it mattered).
There are several concerns here. First,
On Mon, 2008-12-15 at 14:55 -0800, Dan Putler wrote:
> There is one important difference between the Canada NRN and the US
> TIGER data. Specifically, the locational accuracy for the NRN is much
> better than is the case with TIGER. As a result, the need to undertake a
> big effort editing ways to
On Thu, 2008-12-11 at 15:02 -0500, Mepham, Michael wrote:
> My first question has to be “Why are you doing this?”. I have spent
> some time looking through the OSM web site and I understand the
> rational for building street maps where none exist or at least are not
> generally available but that
On Wed, 2008-12-10 at 13:35 -0500, Richard Degelder wrote:
> By the way do you know what they did with the AND import? Did they also
> just load up the map and leave it to the local mappers to correct and
> discrepancies and fix any errors as well? I realize that within places
> like China and In
On Tue, 2008-12-09 at 22:40 -0500, Richard Degelder wrote:
> How did other imports, such as
> the TIGER import, deal with data that was already there?
Heh, we need TIGER FAQ. We didn't handle existing data at all. There
were perhaps one or two counties that got skipped. But, the other 3000
or s
On Thu, 2008-11-27 at 11:20 -0800, Sam Vekemans wrote:
> (aside: What about converting rejected data to 'highway=road'?)
> when new geobase data is available, the script would be the same, only
> look at the road name and road class in close proximity, and add whats
> missing.
This is a very easy
On Wed, 2008-11-26 at 01:40 -0800, Sam Vekemans wrote:
>
>
>
> I do think it was important to have things broken up
> geographically. It
> makes it much easier if something goes bad to find the data,
> remove it,
> an retry.
>
>
15 matches
Mail list logo
