>> http://svn.openstreetmap.org/applications/utils/import/tiger2osm/shape_to_osm-Tiger.py
>>
> Cool stuff! I've been looking at doing the same thing. Which osgeo
> python code are you using?
I'm using the default lib for Fedora - GDAL 1.6.0; release 8.fc11 .
Someone else (in Georgia?) created
On Thu, 2009-11-12 at 15:19 -0500, Mike N. wrote:
> FYI - I applied the experimental script which creates address
> interpolation ways at -
>
> http://svn.openstreetmap.org/applications/utils/import/tiger2osm/shape_to_osm-Tiger.py
>
> The results are at
>
> http://cid-b17e2f1a4d519b13.skydrive.
On Thu, Nov 12, 2009 at 6:43 PM, Frederik Ramm wrote:
> I consider interpolation ways to be an abstract thing also. To convey the
> information, they need to be on each side of the road
The thing is, they don't.
> As long as there is no doubt (for the
> person viewing the situation in an editor)
Hi,
Anthony wrote:
> On Thu, Nov 12, 2009 at 5:41 PM, Frederik Ramm wrote:
>> I would also strongly encourage you to use one such line on each side of the
>> road, instead of putting tags on the road itself. This makes it very clear
>> which side an address is on, better than any tags you can put
On Thu, Nov 12, 2009 at 5:41 PM, Frederik Ramm wrote:
> I would also strongly encourage you to use one such line on each side of the
> road, instead of putting tags on the road itself. This makes it very clear
> which side an address is on, better than any tags you can put on the way, no
> matter
Hi,
Anthony wrote:
> On Thu, Nov 12, 2009 at 4:43 PM, andrzej zaborowski wrote:
>> Every single country has different addressing rules, it's not like
>> this particular scheme is special. That's why someone came up with a
>> tagging scheme that can express all or most of these rules
>
> They di
On Thu, Nov 12, 2009 at 5:32 PM, Mike N. wrote:
>> There are cases with Karlruhe Scheme that need addditional tags like
>> Czech addresses but I haven't heard of such cases from US or other
>> mappers.
>
> I recently started using a new modifier tag addr:inclusion to help in
> accurately tagging
> There are cases with Karlruhe Scheme that need addditional tags like
> Czech addresses but I haven't heard of such cases from US or other
> mappers.
I recently started using a new modifier tag addr:inclusion to help in
accurately tagging my survey data (and added it to the wiki
http://wiki.o
On Thu, Nov 12, 2009 at 5:14 PM, andrzej zaborowski wrote:
> Ian hasn't (yet) mentioned whether this data he deals with contains
> potential address ranges or actual ranges, so I assumed actual.
The fact that it's tagged on the line segments representing the road
centerline pretty much guarantees
On Thu, Nov 12, 2009 at 4:43 PM, andrzej zaborowski wrote:
> Every single country has different addressing rules, it's not like
> this particular scheme is special. That's why someone came up with a
> tagging scheme that can express all or most of these rules
They did? What scheme is that?
My
FYI - I applied the experimental script which creates address interpolation
ways at -
http://svn.openstreetmap.org/applications/utils/import/tiger2osm/shape_to_osm-Tiger.py
The results are at
http://cid-b17e2f1a4d519b13.skydrive.live.com/self.aspx/Public/tl%5E_2009%5E_45045%5E_addrInterpolatio
>>> If we're going to go into detail, no type of interpolation reflects
>>> reality, it's just interpolation.
>>
>> I disagree. An approximation of reality reflects reality.
>
> Physical street surveys will almost never get 100% reality due to missing
> house numbers, etc. Are you proposing to
>> If we're going to go into detail, no type of interpolation reflects
>> reality, it's just interpolation.
>
> I disagree. An approximation of reality reflects reality.
Physical street surveys will almost never get 100% reality due to missing
house numbers, etc. Are you proposing to discour
follow the OSM principle.
map what's on the ground no matter where you are
On 12 Nov 2009, at 11:56 , Dave Hansen wrote:
> On Thu, 2009-11-12 at 11:40 -0800, Apollinaris Schoell wrote:
>> On 12 Nov 2009, at 11:29 , Anthony wrote:
>>> On Thu, Nov 12, 2009 at 9:14 AM, Andy Allan
>>> wrote:
I
On Thu, Nov 12, 2009 at 2:40 PM, Apollinaris Schoell wrote:
> Don't know any place except in US where this has been done.
>
Even if it weren't done anywhere else (which it is, see below), there
are a lot of houses in the US.
>>> how is that easier than the Karlsruhe scheme?
>>
>> It's not really
On Thu, 2009-11-12 at 11:40 -0800, Apollinaris Schoell wrote:
> On 12 Nov 2009, at 11:29 , Anthony wrote:
> > On Thu, Nov 12, 2009 at 9:14 AM, Andy Allan
> > wrote:
> >> It's a fairly well established convention that in OSM it's the
> >> houses/plots, not the road centrelines, that are addressed
On 12 Nov 2009, at 11:29 , Anthony wrote:
> On Thu, Nov 12, 2009 at 9:14 AM, Andy Allan
> wrote:
>> It's a fairly well established convention that in OSM it's the
>> houses/plots, not the road centrelines, that are addressed.
>
> But that doesn't always reflect reality. The reality, at least
This may be stating the obvious, but it's a lot less effort to capture
address ranges for each block than to capture an accurate location for each
individual building. I think that's the primary reason why most geocoding
systems use this approach. But it's not either / or - if you're doing
geocodin
On 12 Nov 2009, at 11:18 , Anthony wrote:
> On Wed, Nov 11, 2009 at 11:17 PM, Apollinaris Schoell
> wrote:
>> On Wed, Nov 11, 2009 at 7:19 PM, Anthony wrote:
>>> It probably has to be a relation. Include a start node, an end
>>> node,
>>> and a list of one or more ways (which are connected t
On Thu, Nov 12, 2009 at 9:14 AM, Andy Allan wrote:
> It's a fairly well established convention that in OSM it's the
> houses/plots, not the road centrelines, that are addressed.
But that doesn't always reflect reality. The reality, at least in
many parts of the world, is that the streets are giv
On Wed, Nov 11, 2009 at 11:26 PM, Ian Dees wrote:
> On Wed, Nov 11, 2009 at 10:17 PM, Apollinaris Schoell
> wrote:
>>
>> On Wed, Nov 11, 2009 at 7:19 PM, Anthony wrote:
>>>
>>> On the other hand, putting the information directly on the way would
>>> be problematic for many reasons. Ranges might
On Wed, Nov 11, 2009 at 11:17 PM, Apollinaris Schoell
wrote:
> On Wed, Nov 11, 2009 at 7:19 PM, Anthony wrote:
>> It probably has to be a relation. Include a start node, an end node,
>> and a list of one or more ways (which are connected to form one
>> logical way).
>>
> the ways have to be spl
Dave Hansen writes:
> The standard OSM user tries to find their street first. The typical US
> OSM experience has gone from, "My street isn't there" to "My street is
> crooked".
And soon it will go to "My house is in the wrong location". In
parts of St. Lawrence County, New York, that's alrea
On Thu, 2009-11-12 at 10:28 -0600, Ian Dees wrote:
>
> Give everyone a chance to work in a constructive way and don't expect
> others to clean the mess bad import left behind.
> No wonder there are only few motivated mappers in US. In Canada they
> do a much
On 12 Nov 2009, at 8:28 , Ian Dees wrote:
> On Thu, Nov 12, 2009 at 10:20 AM, Apollinaris Schoell > wrote:
>
> On 12 Nov 2009, at 6:14 , Andy Allan wrote:
>
> > I disagree there. It's much better to put the effort in during the
> > initial import, than to import things badly and try to fix it up
On Thu, Nov 12, 2009 at 10:20 AM, Apollinaris Schoell wrote:
>
> On 12 Nov 2009, at 6:14 , Andy Allan wrote:
>
> > I disagree there. It's much better to put the effort in during the
> > initial import, than to import things badly and try to fix it up
> > later. We've been working on lots of post-i
On 12 Nov 2009, at 6:14 , Andy Allan wrote:
> I disagree there. It's much better to put the effort in during the
> initial import, than to import things badly and try to fix it up
> later. We've been working on lots of post-import fixups in the last 6
> months and it's much harder than everyone a
Ian Dees wrote:
> * Ok, not "impossible", but the import size would triple and the CPU
> time to compute the new addressing-only ways might make it hard for
> the "regular mapper" to do.
But for no added code and editor complexity.
IMHO the only decent alternative is using a relation for each addr
On Wed, Nov 11, 2009 at 10:17 PM, Apollinaris Schoell wrote:
> On Wed, Nov 11, 2009 at 7:19 PM, Anthony wrote:
>
>>
>> On the other hand, putting the information directly on the way would
>> be problematic for many reasons. Ranges might span multiple ways, and
>> right/left has to be reversed wh
On Wed, Nov 11, 2009 at 7:19 PM, Anthony wrote:
>
> On the other hand, putting the information directly on the way would
> be problematic for many reasons. Ranges might span multiple ways, and
> right/left has to be reversed whenever the way is reversed being the
> most troublesome.
>
> this is
Ian Dees wrote:
> * Ok, not "impossible", but the import size would triple and the CPU
> time to compute the new addressing-only ways might make it hard for
> the "regular mapper" to do.
But for no added code and editor complexity.
IMHO the only decent alternative is using a relation for each addr
On Wed, Nov 11, 2009 at 9:47 PM, andrzej zaborowski wrote:
>
> That's a pretty pessimistic view.
>
>
Sorry, I am pretty grumpy today. The area I'm looking at actually has quite
a few mappers already, so I imagine this data would probably get updated
quickly.
>
> For the record an import I've don
On Wed, Nov 11, 2009 at 9:21 PM, Ian Dees wrote:
> No, I doubt local mappers will improve the data.
If that's true (and I'm really not sure if it is), then it really
shouldn't be in OSM in the first place.
> I sent this mail because
> almost all of the data I've seen available for import in the
On Wed, Nov 11, 2009 at 7:55 PM, andrzej zaborowski wrote:
> Hiya,
>
> 2009/11/12 Ian Dees :
> > I'm looking at some donated street centerline data that has addressing
> data
> > in the form of "Right/Left From Addr" and "Right/Left To Addr" on each
> > street centerline. Is there an accepted way
34 matches
Mail list logo
