Russ Nelson schrieb:
> Oh, look, we have 99% of all roads in the US in OSM. Can you say that
> about any other country besides the exceptional Germany and the (dare
> I say it) imported Netherlands?
In German cities we have 90-100% of the roads, but it's not that good in
remote rural areas. The
Dave Hansen wrote:
> On Mon, 2009-11-16 at 15:05 +, Andy Allan wrote:
>> So please, turn away from imports and work on getting mappers in
>> charge, especially out pounding the streets. The outcome will be much,
>> much better in the end, and that end will come much, much quicker.
>
> I think
2009/11/16 Andy Allan
>
> Yes. Please don't include "this point is within such-and-such a
> polygon" data onto the point itself, it's redundant information and
> not helpful. When a county border is changed by legislation, then
> moving the border of the county should be sufficient for a mapper.
On Sat, Nov 14, 2009 at 1:40 AM, Mike N. wrote:
>
>
>
>
>
>
> I believe people have been saying that this information is not necessary,
> and is_in is also not necessary for 99% of cases, so we can save space by
> not including that for the Karlsruhe Schema. (But I don't know how the
> name
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
2009/11/15 Anthony :
> On Sat, Nov 14, 2009 at 9:05 PM, andrzej zaborowski wrote:
>> I agree with
>> Anthony that these tags are useless *except* this one tag, the Id *is*
>> useful, please don't remove it.
>
> What's useful about it? Or to ask the question a different way, what
> is the tag supp
2009/11/15 Apollinaris Schoell :
> copying is very common for all motorways and other ways with separated
> lanes.
And this is ok too, it means that both these ways in TIGER are one way
with the given Id, this is just the information any automated process
will be looking for.
> the worst example
On Sat, Nov 14, 2009 at 9:05 PM, andrzej zaborowski wrote:
> I agree with
> Anthony that these tags are useless *except* this one tag, the Id *is*
> useful, please don't remove it.
What's useful about it? Or to ask the question a different way, what
is the tag supposed to mean?
On Sat, Nov 14,
On 14 Nov 2009, at 18:05 , andrzej zaborowski wrote:
> 2009/11/15 Apollinaris Schoell :
>> matching Tiger id's is a very bad idea. you need to compare
>> geometries.
>> during edits ways are split, merged copied moved, deleted nodes
>> added node,
>
> Most of these operations are not a proble
2009/11/15 andrzej zaborowski :
> I agree with
> Anthony that these tags are useless *except* this one tag, the Id *is*
> useful, please don't remove it.
To clarify what I mean, a good measure is probably whether you're
changing the name on the road. If you're changing the geometry
(splitting, me
2009/11/15 Apollinaris Schoell :
> matching Tiger id's is a very bad idea. you need to compare geometries.
> during edits ways are split, merged copied moved, deleted nodes added node,
Most of these operations are not a problem (except copying a whole way
to somewhere else), the changed geometry i
>
> 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 will need to do all of the geometry
> corrections th
On Sat, 2009-11-14 at 13:49 +0100, andrzej zaborowski wrote:
> > In San Francisco, for divided highways the old TIGER data used to
> bow in to a point every block and we had, I think, automated ways to
> split those out in to two straight lines. This is reflected with
> little bows on the address l
On Nov 14, 2009, at 5:49 AM, andrzej zaborowski wrote:
> Hi,
>
> 2009/11/14 SteveC :
>> In Denver the houses are all set back a lot further, so some way to say 'on
>> north-south roads, set back X feet' might help a lot. Or, in JOSM just
>> search for all the ways that make up the addressing o
2009/11/14 andrzej zaborowski :
> I've done a similar import of address data in my area and when writing
> the converter I forgot to do the projection the first time, this
> resulted in a similar effect to what you describe. I've not seen
> Dave's data but looking at the code he's using there's no
Hi,
2009/11/14 SteveC :
> In Denver the houses are all set back a lot further, so some way to say 'on
> north-south roads, set back X feet' might help a lot. Or, in JOSM just search
> for all the ways that make up the addressing on one side of the street and
> move them manually. Many times for
Dave
I've looked at the two you sent me and they're both basically fine but for two
things.
In Denver the houses are all set back a lot further, so some way to say 'on
north-south roads, set back X feet' might help a lot. Or, in JOSM just search
for all the ways that make up the addressing on
> http://svn.openstreetmap.org/applications/utils/import/tiger2osm/shape_to_osm-Tiger.py
> We'll work on making sure that these data look good and I think some
> people have some plans on how to get these integrated a bit at a time.
Thanks to those who worked on the namefinder - it worked GREA
Can I have SF county, CA please and Arapahoe County, CO...?
Yours &c.
Steve
On Nov 13, 2009, at 4:57 PM, Dave Hansen wrote:
> So, just like the original TIGER import, I'm now grossly stealing
> someone else's code:
>
> http://svn.openstreetmap.org/applications/utils/import/tiger2osm/shape_to_o
19 matches
Mail list logo
