Lennard wrote:
On 6-5-2011 20:44, Pierre-Alain Dorange wrote:
I could not really help you (i don't know your region, but as i can see
(using JOSM) there is no admin relation in this area, so few clues to
help nomatim to find location.
The entire Netherlands is covered by admin relations.
Maarten Deen md...@xs4all.nl wrote:
I was unaware I still had the country wrong for some places, I
thought I'd
found and fixed all these. Recalculating the street now produces the
right
result (as you can see if you re-do your search) so I'll do another
forced
update and try and
On 6-5-2011 20:44, Pierre-Alain Dorange wrote:
I could not really help you (i don't know your region, but as i can see
(using JOSM) there is no admin relation in this area, so few clues to
help nomatim to find location.
The entire Netherlands is covered by admin relations. Of course,
Lennard l...@xs4all.nl wrote:
I could not really help you (i don't know your region, but as i can see
(using JOSM) there is no admin relation in this area, so few clues to
help nomatim to find location.
The entire Netherlands is covered by admin relations. Of course,
occasionally,
On 6-5-2011 22:46, Pierre-Alain Dorange wrote:
OK, that's the admin relation Nominatim used to link the request
street to Peel en Maas.
Correct. It's correct, given the data. The real question is why it was
also categorised as being in Belgium.
I hope you could get them soon.
We'd have
Lennard l...@xs4all.nl wrote:
OK, that's the admin relation Nominatim used to link the request
street to Peel en Maas.
Correct. It's correct, given the data. The real question is why it was
also categorised as being in Belgium.
Following MapQuest Nominatim link (for Belgium response) :
Maarten Deen md...@xs4all.nl wrote:
Nominatim use them (boundariy relations) efficiently.
The lookup may be efficient, it is frequently wrong and again dependent
of correct and complete admin_levels.
Currently it places every street where I live (in the Netherlands) in
Belgium and
The lookup may be efficient, it is frequently wrong and again dependent of
correct and complete admin_levels.
Currently it places every street where I live (in the Netherlands) in
Belgium and does not specify a town with it.
Looking for Jacob van Marisring returns Jacob van Marisring, België
Felix Hartmann extremecar...@gmail.com wrote:
Nope, it makes sense all the time. Cause boundaries really are not ment
for deducting information onto what's inside. This really slows down any
kind of processing (much much more than having data duplicated which
only takes up a bit more disk
On Wed, 4 May 2011 08:07:07 +0200, pdora...@mac.com (Pierre-Alain
Dorange) wrote:
Felix Hartmann extremecar...@gmail.com wrote:
Nope, it makes sense all the time. Cause boundaries really are not
ment
for deducting information onto what's inside. This really slows down
any
kind of processing
2011/5/4 Maarten Deen md...@xs4all.nl:
On Wed, 4 May 2011 08:07:07 +0200, pdora...@mac.com (Pierre-Alain Dorange)
wrote:
Felix Hartmann extremecar...@gmail.com wrote:
Nope, it makes sense all the time. Cause boundaries really are not ment
for deducting information onto what's inside. This
On 5/4/2011 7:58 AM, Jaak Laineste wrote:
Regarding user interface: I would add quick street selector feature
to JOSM (and other editors) - when you open PresetAnnotationsAddress
screen, then instead of text field it would have buttons to select
quickly up to 5 nearest streetnames. I would
2011/5/4 Jaak Laineste jaak.laine...@gmail.com:
Regarding user interface: I would add quick street selector feature
to JOSM (and other editors)
a workaround to improve usability would be to enable autocompletion of
addr:street with the values of the name-keys of the highways.
cheers,
Martin
Hello,
It looks like trivial suggestion, but could not find any past
discussions with quick search.
Is there good reason to add addr:country, addr:county, addr:city and
other regional tags to all the address tags, if OSM database already
has administrative regions for given area? These admin
On 3 May 2011, at 08:57, Jaak Laineste wrote:
Hello,
It looks like trivial suggestion, but could not find any past
discussions with quick search.
Is there good reason to add addr:country, addr:county, addr:city and
other regional tags to all the address tags, if OSM database already
Jaak Laineste jaak.laineste at gmail.com writes:
Is there good reason to add addr:country, addr:county, addr:city and
other regional tags to all the address tags, if OSM database already
has administrative regions for given area?
I don't think so, except in cases where the postal regions are
Jaak Laineste wrote:
Is there good reason to add addr:country, addr:county, addr:city and
other regional tags to all the address tags, if OSM database already
has administrative regions for given area?
I can't speak for the other tags, but addr:city is not the same as
is_in:city. I have an
Jaak Laineste jaak.laineste at gmail.com writes:
Is there good reason to add addr:country, addr:county, addr:city and
other regional tags to all the address tags, if OSM database already
has administrative regions for given area?
I think addr:country can be identified by existing borders, but
2011/5/3 Jo winfi...@gmail.com:
What I do to avoid most redundancy, is to create an associatedStreet
relation. ... I add more than one street to them though, even if JOSM
complains about that.
it is not just JOSM complaining about this, it is against the spec:
Members
Way/nodeRole
On 03.05.2011 10:09, Thomas Davie wrote:
On 3 May 2011, at 08:57, Jaak Laineste wrote:
Hello,
It looks like trivial suggestion, but could not find any past
discussions with quick search.
Is there good reason to add addr:country, addr:county, addr:city and
other regional tags to all the
The very first I did, I did it according to 'spec':
http://www.openstreetmap.org/browse/changeset/7595148
The result is a ridiculous amount of 4 relations for a street of less than
1,5 km in length. Some of which only contain one house. And each of them
containing redundant name, addr:city,
2011/5/3 Jo winfi...@gmail.com:
The very first I did, I did it according to 'spec':
http://www.openstreetmap.org/browse/changeset/7595148
The result is a ridiculous amount of 4 relations for a street of less than
1,5 km in length. Some of which only contain one house. And each of them
On Tue, May 3, 2011 at 2:22 PM, Felix Hartmann extremecar...@gmail.comwrote:
+1
boundaries are too often wrong or incomplete or if someone deletes them
accidentally (or renames them slightly)
again the is_in discussion
All these arguments above are also valid when you put the full
Hmm, I'm convinced the associatedStreet relation is the most elegant way to
solve the redundancy problem. The biggest issue with it is the one street
per relation limitation, which I don't understand where it comes from. So,
as far as I'm concerned, it'd be better to redefine it.
Polyglot
Hi,
On 05/03/2011 03:12 PM, Jo wrote:
Hmm, I'm convinced the associatedStreet relation is the most elegant way
to solve the redundancy problem. The biggest issue with it is the one
street per relation limitation, which I don't understand where it comes
from. So, as far as I'm concerned, it'd be
Jo wrote:
Hmm, I'm convinced the associatedStreet relation is the most elegant way
to solve the redundancy problem.
There is no redundancy problem.
No, really. There is nothing fundamentally wrong with redundancy.
Redundancy per se doesn't cause any harm to our database. Looking at
taginfo and
On 3 May 2011 15:03:07 +0200, M?rtin Koppenhoefer
dieterdre...@gmail.com wrote:
Yes, I know. In your case (just one house) the relation indeed seems
to be far less adequate in respect to simple tags. Relations add a
complexity that is mostly not desirable IMHO for cases like
housenumbers. The
Felix Hartmann extremecarver at gmail.com writes:
Cause boundaries really are not
ment for deducting information onto what's inside. This really slows
down any kind of processing (much much more than having data
duplicated which only takes up a bit more disk space).
It's one thing to say that to
2011/5/3 Ed Avis e...@waniasset.com:
It's one thing to say that to speed up and simplify processing, there should
be
duplicated data. Quite another to say that every contributor, on every object
that has an address, should manually add several redundant tags.
Let's tag the information that
On Tue, May 3, 2011 at 3:50 PM, Felix Hartmann extremecar...@gmail.comwrote:
Cause boundaries really are not ment for deducting information onto what's
inside.
I don't know what to say against that
Pieren
___
talk mailing list
On 3 May 2011 15:53, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote:
You seem to imply that relations are faster / less manual work
requiring when entering addresses manually with one of the OSM
editors, but from my own experience they require at least the same
(manual) work, if not more.
Select some street parts, building outlines and nodes. Press the button to
create a new relation and add them. Then add the properties to the relation.
That really doesn't take longer than adding those properties directly to the
elements themselves. Of course, I always have the relation overview
2011/5/3 M∡rtin Koppenhoefer dieterdre...@gmail.com:
You seem to imply that relations are faster / less manual work
requiring when entering addresses manually with one of the OSM
editors, but from my own experience they require at least the same
(manual) work, if not more.
Creating relation
2011/5/3 Jaak Laineste jaak.laine...@gmail.com:
2011/5/3 M∡rtin Koppenhoefer dieterdre...@gmail.com:
Creating relation could be same, or even more extra work, this is
correct (but fixable in editor level).
actually it will (with explicit numbers without interpolation) not be
possible at the
M∡rtin Koppenhoefer dieterdreist at gmail.com writes:
Let's tag the information that is needed, but not restate the same thing in
several different ways. Then if some different presentation of that info is
needed, this can be done in a separate post-processing step by a computer, not
by people.
Le 03/05/2011 16:54, Pieren a écrit :
On Tue, May 3, 2011 at 3:50 PM, Felix Hartmann
extremecar...@gmail.com mailto:extremecar...@gmail.com wrote:
Cause boundaries really are not ment for deducting information
onto what's inside.
I don't know what to say against that
Pieren
36 matches
Mail list logo
