Could someone[1] setup a web-service where you send it a lat/lon and
it returns a list of all boundaries that point is within? So just one
website imports the boundary data instead of everyone having to know
how to do the 'is within' search[2].
I think you might be able to do this with
Is there a real need for is_in tags or have admin boundaries replaced the need?
It seems there is a lot of redundancy going on for example node id = 17652780
aeroway = aerodrome
closest_town = Newcastle, New South Wales
ele = 9
iata = NTL
icao = YWLM
is_in = Australia, NSW, New South Wales
On 28 Jul 2009, at 13:43, John Smith wrote:
Is there a real need for is_in tags or have admin boundaries
replaced the need?
Admin boundaries are the new way of doing this. The is_in tag was the
early way of trying to show a hierarchy of admin areas.
Shaun
smime.p7s
Description:
--- On Tue, 28/7/09, Shaun McDonald sh...@shaunmcdonald.me.uk wrote:
Admin boundaries are the new way of doing this. The is_in
tag was the early way of trying to show a hierarchy of admin
areas.
Ok, so is_in is redundant.
There was talk on the dev list about removing a bunch of tiger tags
Shaun McDonald wrote:
On 28 Jul 2009, at 13:43, John Smith wrote:
Is there a real need for is_in tags or have admin boundaries replaced
the need?
Admin boundaries are the new way of doing this. The is_in tag was the
early way of trying to show a hierarchy of admin areas.
It is
Perhaps the more appropriate question would be what are appropriate tag keys
that could be used in combination with the tag place=*?
So far all I can come up with is name and possibly source. I'm primarily only
looking at aussie data so I may have over looked things.
is_in seems to have
--- On Tue, 28/7/09, David Earl da...@frankieandshadow.com wrote:
It is still *very* helpful to have is_in present though. It
is much easier to present this information in a search than
to do polygon tests which requires a whole new algorithm
(desirable though that is), and of course,
John Smith wrote:
--- On Tue, 28/7/09, David Earl da...@frankieandshadow.com wrote:
It is still *very* helpful to have is_in present though. It is much
easier to present this information in a search than to do polygon
tests which requires a whole new algorithm (desirable though that
is),
2009/7/28 John Smith delta_foxt...@yahoo.com:
Perhaps the more appropriate question would be what are appropriate tag keys
that could be used in combination with the tag place=*?
So far all I can come up with is name and possibly source. I'm primarily only
looking at aussie data so I may
--- On Tue, 28/7/09, David Earl da...@frankieandshadow.com wrote:
But until we do, the existing mechanism does no harm, and
Apart from massively bloating the database due to massive amounts of redundant
and/or useless information that doesn't gain us anything.
as I said, you don't always
--- On Tue, 28/7/09, andrzej zaborowski balr...@gmail.com wrote:
What if boundary is not defined but the hierarchy is
defined, such as
with post codes? Should people invent boundary
polygons based on just
what nodes/ways belong to the area? I hope not.
Why spend just as much time tagging
On 28 Jul 2009, at 15:35, John Smith wrote:
--- On Tue, 28/7/09, andrzej zaborowski balr...@gmail.com wrote:
What if boundary is not defined but the hierarchy is
defined, such as
with post codes? Should people invent boundary
polygons based on just
what nodes/ways belong to the area? I
But until we do, the existing mechanism does no harm, and as I said, you
don't always know the boundary while you do know where the place is.
Determining the inclusion of every place in the database, even if we had
complete information, is massively more complex than simply being told
the
--- On Tue, 28/7/09, Shaun McDonald sh...@shaunmcdonald.me.uk wrote:
Only use the is_in tag on the place nodes rather than every
node.
Why?
The reasoning I've been given so far is for routing, but to find such
information routing software would have to look at all nodes near by until it
--- On Tue, 28/7/09, Donald Allwright donald_allwri...@yahoo.com wrote:
(I'm not volunteering to write the checker, but I would
certainly be willing to spend time looking at any errors
thus detected).
This came up because I've started writing a checker to find certain tag
combinations and
2009/7/28 John Smith delta_foxt...@yahoo.com:
--- On Tue, 28/7/09, andrzej zaborowski balr...@gmail.com wrote:
What if boundary is not defined but the hierarchy is
defined, such as
with post codes? Should people invent boundary
polygons based on just
what nodes/ways belong to the area? I
John Smith wrote:
--- On Tue, 28/7/09, Shaun McDonald sh...@shaunmcdonald.me.uk
wrote:
Only use the is_in tag on the place nodes rather than every node.
Why?
The reasoning I've been given so far is for routing, but to find such
information routing software would have to look at all
--- On Tue, 28/7/09, andrzej zaborowski balr...@gmail.com wrote:
Both for the time spent tagging and space used in database,
perhaps
there might be some saving from using polygons but it
depends on the
exact scenario. Either way, don't add the tags you
I doubt I can agree that using
John Smith wrote:
--- On Tue, 28/7/09, Shaun McDonald sh...@shaunmcdonald.me.uk wrote:
Admin boundaries are the new way of doing this. The is_in
tag was the early way of trying to show a hierarchy of admin
areas.
Ok, so is_in is redundant.
There was talk on the dev list about
--- On Tue, 28/7/09, David Earl da...@frankieandshadow.com wrote:
We can give ourselves a helping hand here if we keep
is_in.
That's assuming the information contained in it is useful to begin with, as I
keep stating the information I've seen is inconsistent so that's not helping
any one.
--- On Tue, 28/7/09, MarkS o...@redcake.co.uk wrote:
We need to be careful about removing tags because it could
cause
renderers to fail (or at least not work as expected). For
example, I
think the is_in tag is added after the place name in mkgmap
when
creating the city POIs.
That's
On Tue, Jul 28, 2009 at 4:09 PM, David Earlda...@frankieandshadow.com wrote:
The reason I gave was for name searching, not routing. It allows the
result of a search to be given a descriptive context that isn't
currently possible any other way.
It allows the result of a search to be given a
--- On Tue, 28/7/09, Andy Allan gravityst...@gmail.com wrote:
Let's stop the is_in debate - yes, they are useful to data
consumers,
no, they shouldn't be in OSM itself, and no, nobody has yet
stepped up
to sort it out.
U I am stepping up to sort it out, at least for some parts of
John Smith wrote:
--- On Tue, 28/7/09, MarkS o...@redcake.co.uk wrote:
We need to be careful about removing tags because it could
cause
renderers to fail (or at least not work as expected). For
example, I
think the is_in tag is added after the place name in mkgmap
when
creating the city
2009/7/28 John Smith delta_foxt...@yahoo.com:
--- On Tue, 28/7/09, David Earl da...@frankieandshadow.com wrote:
We can give ourselves a helping hand here if we keep
is_in.
That's assuming the information contained in it is useful to begin with, as I
keep stating the information I've seen is
--- On Tue, 28/7/09, andrzej zaborowski balr...@gmail.com wrote:
Data being wrong is a moot point, it doesn't speak for
either is_in
tags or boundary polygons and neither help make data more
correct
really.
data being stored consistently is the point.
2009/7/28 Andy Allan gravityst...@gmail.com:
Let's stop the is_in debate - yes, they are useful to data consumers,
no, they shouldn't be in OSM itself, and no, nobody has yet stepped up
to sort it out.
One of the two ways to indicate belonging to an area should not be in
OSM, agreed. Why's
--- On Tue, 28/7/09, MarkS o...@redcake.co.uk wrote:
I'm not against getting rid of is_in, I just think we need
to manage the
change over a fair period of time to give the renderers a
chance to
catch up.
It's irrelevant if place nodes don't already have is_in and instead of adding
Andy Allan wrote:
On Tue, Jul 28, 2009 at 4:09 PM, David Earlda...@frankieandshadow.com wrote:
The reason I gave was for name searching, not routing. It allows the
result of a search to be given a descriptive context that isn't
currently possible any other way.
It allows the result of a
On Tue, Jul 28, 2009 at 5:20 PM, David Earlda...@frankieandshadow.com wrote:
Andy Allan wrote:
On Tue, Jul 28, 2009 at 4:09 PM, David Earlda...@frankieandshadow.com
wrote:
The reason I gave was for name searching, not routing. It allows the
result of a search to be given a descriptive
Could someone[1] setup a web-service where you send it a lat/lon and
it returns a list of all boundaries that point is within? So just one
website imports the boundary data instead of everyone having to know
how to do the 'is within' search[2].
Namefinder could then query this to add its own
Have a look at boundaries.pl in the wiki
-- Urspr. Mitt. --
Betreff: Re: [OSM-talk] is_in and similar tags
Von: OJ W ojwli...@googlemail.com
Datum: 28.07.2009 19:33
Could someone[1] setup a web-service where you send it a lat/lon and
it returns a list of all boundaries that point is within? So
OJ W ojwli...@googlemail.com schrieb:
Could someone[1] setup a web-service where you send it a lat/lon and
it returns a list of all boundaries that point is within? So just one
website imports the boundary data instead of everyone having to know
how to do the 'is within' search[2].
I think
--- On Tue, 28/7/09, David Earl da...@frankieandshadow.com wrote:
If there's errors in them, I don't see the difference
between those and any other errors in the map.
Maybe someone was trying to do something about error, and maybe it just
happened to turn into this debate?
--- On Tue, 28/7/09, David Earl da...@frankieandshadow.com wrote:
I don't see why you think people entering boundary data
will be more consistent than in entering anything else - we
have huge inconsistencies all over the place. Our method of
tagging encourages it.
Because in theory there
--- On Tue, 28/7/09, andrzej zaborowski balr...@gmail.com wrote:
One of the two ways to indicate belonging to an area should
not be in
OSM, agreed. Why's this the is_in tags, is the final
rationale the
space saving?
By using boundaries you can effectively tag every node, way and relation
2009/7/29 John Smith delta_foxt...@yahoo.com:
Or as a less practical example take two ways that cross one
another
(one may be a bridge or tunnel), one officially belonging
to county A
or postcode A and the other to B.
Exactly, you wouldn't need to split the way, by having a boundary it
--- On Tue, 28/7/09, andrzej zaborowski balr...@gmail.com wrote:
No no, I wasn't talking about ways crossing a postcode area
boundary.
Just two ways crossing one another belonging entirely to
different
divisions each and where do you invent the boundary
then. Possibly
this is not found in
38 matches
Mail list logo
