Re: [OSM-talk] Skip geographical (redundant) address tags

[Maarten Deen]

On Wed, 4 May 2011 08:07:07 +0200, pdora...@mac.com (Pierre-Alain 
Dorange) wrote:

Felix Hartmann  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 space).


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 does not specify a town with it.
Looking for "Jacob van Marisring" returns "Jacob van Marisring, België 
51.32,51.32 14558705 (Residential)". Searching for "Jacob van Marisring, 
Helden" even returns an error.


Also note that in the FAQ page of nominatim, the suggestion is done to 
fix errors by adding addr: or is_in: tags.


Regards,
Maarten


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Geofabrik Download Server Update

[Frederik Ramm]

Hendrik,

On 05/04/11 00:44, Hendrik Oesterlin wrote:

It is included, but ADSL in New Caledonia is expensive and therefor
quite slow (256kb downstream).


I have added a New Caledonia extract, and it should be there daily from 
tomorrow.


Bye
Frederik

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New Logo in the Wiki

[Frederik Ramm]

Hi,

On 05/04/11 03:23, Serge Wroclawski wrote:

Dave, if you have a suggestion that would let us communicate in real
time (not over weeks via email) then please share this with the group.


The alternative to communicating in real-time is fundamentally changing 
your organisational structure to reduce international decision-making to 
an absolute bare minimum by devolution.


For example, move to a kind of distributed software/database 
architecture, incorporate OpenStreetMap Australia, let them collect 
their own funds, operate their own database, make their own decisions, 
have their own logo, have their own project main page, have their own 
strategy working group, have their own license, and so on.


Same for other continents or time zone bands.

I know it sounds crazy and it is certainly not something we can do 
tomorrow - but then again many of us are better (and more comfortable) 
solving technical problems than dealing with humans.


I am sure there must be other international projects where there is no 
centrally planned strategy and central funding/operations, just a very 
thin and powerless international body in which the regional/national 
organisations are members, and the latter have all the funding, 
operations, and manpower.


Bye
Frederik

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Pierre-Alain Dorange]

Felix Hartmann  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 space).

Nominatim use them (boundariy relations) efficiently.

Adding extra data on every address is not a bit more space it can be
huge when you add addresses on every house of a city. And that also
really slow down things.

-- 
Pierre-Alain Dorange
OSM experiences : 


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Geofabrik Download Server Update

[Frederik Ramm]

Phil,

On 05/04/11 01:48, Phil Endecott wrote:

I need to use simplified polygons; cutting out a country with a 15k
node polygon would take forever.


Is your point-in-polygon test O(N) in the size of the polygon? You can
do much better than that.


I use Osmosis, which in turn uses whatever Java offers in its 
"Area.contains()" method. If you have interesting improvements to offer, 
why not discuss on the osmosis mailing list, or even hack them into 
svn.openstreetmap.org/applications/utils/osmosis/trunk/areafilter/src/org/openstreetmap/osmosis/areafilter/v0_6/PolygonFilter.java 
directly ;)


Bye
Frederik

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New Logo in the Wiki

[Anders Arnholm]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

2011-05-04 03:23, Serge Wroclawski skrev:

> Dave, if you have a suggestion that would let us communicate in real
> time (not over weeks via email) then please share this with the group.

The problem is that with the need for real time, at best 1/3 of the
world is at sleeping time at every given moment of the day. This 1/3
will potentially feel left out. Real time meetings as such always is a
major problem in activities spread around the world.

The only solutions so far I seen so far that might work is to flatten
the earth and that way remove time zones. That may not be a practical
one thou.

With the limitations of it have to be real time, the question is not how
to find a solutions but who should be asleep while the meetings go on.

/ Balp

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3A3g4ACgkQtbR3SXmySrdQxACffb2bVJSM72I1Mpj5G08nryZD
b3wAn0WdXzoYMuH78qMxQ7nxph7txoH7
=8/Ki
-END PGP SIGNATURE-

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New Logo in the Wiki

[Serge Wroclawski]

Dave,

This issue comes up constantly and no group has found any solutions
which are ideal.

Some folks suggest meetings using, say Gnome meeting, and then they're
doled it's hard to set up, so Skype is suggested. Then some say Skype
is proprietary, so we should switch to a phone conference system.
Those cost money, and even when we use them, often there's noise, or
it's hard to hear people, and significant time is spent dealing with
phone issues. It's then suggested IRC is better because there are no
audio issues. Then some, like you, complain about IRC.

The time issue isn't solvable either. Finding a time that works with
everyone, with different schedules, is hard enough. Now add the fact
that OSM members are distributed around the world, and the problem is
simply not solvable.

Many of us have tried tools to help with this, like Doodle, and we've
tried having meetings at different times, and neither one works.
People always feel left out if they can't attend, and having different
meeting times just makes people apt to miss the meetings, and then you
get different meetings with non-overlapping attendees.

The frustration you hear from folks like Steve stems from the fact
that folks like Grant and the others in the project put in their
personal time and effort to make this project as good as they can make
it, and so often instead of due praise for working so diligently
trying to make the project succeed, they get a lot of criticism from
the community. It's easy for us to forget how much time and energy it
takes to do the kind of work Grant and others do, and while I'm not
saying they or anyone else is immune from criticism, I think that it
needs to be measured against their good works.

Dave, if you have a suggestion that would let us communicate in real
time (not over weeks via email) then please share this with the group.

- Serge

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New Logo in the Wiki

[Mikel Maron]

We also discuss frequently on the strategic mailing list, so there's 
asynchronous options as well to participate. For people who want to discuss 
things reasonably, that is.

 == Mikel Maron ==
+14152835207 @mikel s:mikelmaron





From: Dave F. 
To: OSM Talk 
Sent: Tue, May 3, 2011 6:53:45 PM
Subject: Re: [OSM-talk] New Logo in the Wiki

On 02/05/2011 13:36, Grant Slater wrote:
> OK, lets find a time that works better. World Time Server Meeting
> planner: http://bit.ly/kBuc2L
> 1pm UTC seems like the best option to me or what do you think? Or
> maybe we should alternate?

What part of "Don't use IRC" did you not comprehend?

Just because you've got used to having disturbed sleep cycles does not make it 
a 
universal useful discussion forum.

If you & OSMF & SWG (or whatever you call yourselves nowadays) insist on using 
IRC you'll have to put up with the dissenting calls of intentional exclusivity.

Dave F.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New Logo in the Wiki

[Steve Coast]

Everything would be better if Dave F. was in charge. The trains would 
run on time, logos would go through his personal approval process and 
unicorns would frolic near a turquoise lake in the sun.


So, anyway, Grant was trying to be nice to you and offering to bring you 
in to the process that everyone else is happy with. Don't throw it back 
in his face.


Steve


On 5/3/2011 4:53 PM, Dave F. wrote:

On 02/05/2011 13:36, Grant Slater wrote:

OK, lets find a time that works better. World Time Server Meeting
planner: http://bit.ly/kBuc2L
1pm UTC seems like the best option to me or what do you think? Or
maybe we should alternate?


What part of "Don't use IRC" did you not comprehend?

Just because you've got used to having disturbed sleep cycles does not 
make it a universal useful discussion forum.


If you & OSMF & SWG (or whatever you call yourselves nowadays) insist 
on using IRC you'll have to put up with the dissenting calls of 
intentional exclusivity.


Dave F.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New Logo in the Wiki

[Dave F.]

On 02/05/2011 13:36, Grant Slater wrote:

OK, lets find a time that works better. World Time Server Meeting
planner: http://bit.ly/kBuc2L
1pm UTC seems like the best option to me or what do you think? Or
maybe we should alternate?


What part of "Don't use IRC" did you not comprehend?

Just because you've got used to having disturbed sleep cycles does not 
make it a universal useful discussion forum.


If you & OSMF & SWG (or whatever you call yourselves nowadays) insist on 
using IRC you'll have to put up with the dissenting calls of intentional 
exclusivity.


Dave F.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Geofabrik Download Server Update

[Phil Endecott]

Hi Frederik,

Excuse me for jumping in here without knowing much of the background, but:

Frederik Ramm wrote:
I need to use simplified polygons; 
cutting out a country with a 15k node polygon would take forever.


Is your point-in-polygon test O(N) in the size of the polygon?  You can 
do much better than that.



Regards,  Phil.






___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Geofabrik Download Server Update

[Hendrik Oesterlin]

"Frederik Ramm" wrote on 03/05/2011 at 21:59:45 +1100
subject "[OSM-talk] Geofabrik Download Server Update" :

> I'll check but I think that the NC area should be in the 
> "australia+oceania" extract.

It is included, but ADSL in New Caledonia is expensive and therefor
quite slow (256kb downstream).

I downloaded it yesterday to update both my New Zealand and New
Caledonia map.

Maybe you could make one Oceania extract for the hole pacific ocean,
just excluding Australia an New Zealand. I guess that 95% of data
volume is located in this two island and the rest of Oceania will be
fast to download even if I get the Easter Island, Samoa, Hawaii en
Tahiti if I only need New Caledonia.

Cutting the extract with osmosis is not a problem and very fast.

-- 
Sincerely 
Hendrik Oesterlin - New Caledonia


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] When advertising is good

[Felix Hartmann]

The biggest problem we have is that were not important enough and too 
cluttered to attract in map adverts yet.


I think in the long run, it's not about adverts around the map, but ads 
in the map (of course the database should be advert free). Als our maps 
are still mainly for looking at, maximum autorouting, but few to noone 
uses them to search for specific stuff, so there is less incentive to 
promote your business by buying a logo for it (smallest thing to start 
with).


Google has to pay for map data, and still makes enough money with in map 
adverts to more than cover costs, but we miss a system for map 
producers, that is as simple as google adsense for websites, to place in 
map adverts.

I often think about how and where would be a good start to get it going!

On 03.05.2011 21:25, Nic Roets wrote:

One or two people on the list said that they avoid advertising where
ever they can. I know advertising can be annoying when the same add
appears 10 times in a row, but I just want to explain a few things.

Let's look at the example of a restaurant that is working below
capacity. It can be because they recently opened. It can be because
they are not located on a busy corner. So they have waiters and chefs
not working at peak productivity. They have freshly prepared food
going to waste.

This is a problem that on demand location based advertising can solve,
provided people are willing to accept it in their lives: The
restaurant gets more patrons. Those patrons no longer go to other
restaurants. The other restaurants are now able to serve the remaining
patrons faster.

And the same argument does for most retail and service business.

The great thing about OSM is that we are driving the cost of maps to
$0. If media corporation have annoying ads, people will simply switch.
The media corporation and the advertiser (the restaurant) will now
need to work together to give you the maps at a cost "below 0". My
guess is that it will be in the form of coupons or other specials. "If
you order the OSM special, you get a free softdrink with your burger".

So next time you want to embed maknik in website, consider the
advantages of embedding MapQuest instead.

(And no, I do not have affiliation with MapQuest or any media company).

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Geofabrik Download Server Update

[Frederik Ramm]

Hi,

Matthias Julius wrote:

One option would be to run osmosis with clipIncompleteEntities=false
(the default).  That would not increase the burden on your box and still
allow the extracts to be merged.  Of course, this would leave it up to
the data consumer to deal with the incomplete ways and relations.


Yes. I somewhat fear the number of "i am getting a strange error in my 
program" emails that this would cause.


Merging extracts is a niche operation and not the main purpose of what I 
am doing. For someone who wants to mix and merge at will, it would be 
much better to simply divide the world in lots of squares and select 
from those. The expensive polygon cutting could be dropped completely. 
It is possible that a process for doing that can be derived from those 
who do regular Garmin maps. If done properly, it would even be possible 
to have a web interface where you can select your area of interest, and 
a matching extract is then merged live from pre-made squares...



In some ways this is even preferable because it would preserve the
boundary of the extract.  Otherewise you get a fuzzy boundary and the
consuming tools have no way of knowing the original boundary.


Yes but if you start looking at this closely then the only thing you 
know is that the boundary must be somewhere between nodes X and Y so 
that doesn't get you far.



Do your polygons really overlap?  I think it would be ideal if the
shared the nodes.


No, that would kill the process. I need to use simplified polygons; 
cutting out a country with a 15k node polygon would take forever. And it 
is impossible to simplify the polygons and still make sure that each 
boundary is contained completely in the respective country file, so they 
have to overlap.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Geofabrik Download Server Update

[Matthias Julius]

Frederik Ramm  writes:

> Matthias,
>
> Matthias Julius wrote:
>> But, I need to point out again that theese extracts are not quite as
>> useful as they could be, IMHO. Unless something has been changed,
>> ways that cross the bounding polygon are trunkated at the last node
>> inside the polygon.
>
> I have started to slowly introduce extracts built with the
> --complete-ways option, but not all extracts have that yet. In Europe,
> all sub-country extracts have it but countries don't, so you should be
> able to join two German Laender or two French regions, but you will
> encounter problems when joining a part of Germany with a part of
> France. I'm working on that but even a box with 90 GB of RAM disk has
> a hard time splitting Europe into countries with --complete-ways.

One option would be to run osmosis with clipIncompleteEntities=false
(the default).  That would not increase the burden on your box and still
allow the extracts to be merged.  Of course, this would leave it up to
the data consumer to deal with the incomplete ways and relations.

In some ways this is even preferable because it would preserve the
boundary of the extract.  Otherewise you get a fuzzy boundary and the
consuming tools have no way of knowing the original boundary.
Alternatively, the boundary polygon could be stored in the file.
Unfortunately, so far the file formats only support rectangular bounding
boxes.

>
> Note that two other preconditions exist for a successful join of
> neighbouring regions. First, the polygons I use for cutting must
> actually overlap. They usually do but every now and then I encounter a
> little bit of no man's land due to polygon simplification. Second, you
> have to use software that properly eliminates the double elements; I'm
> not sure if Osmosis does that.

If it doesn't than this is the chance to fix it.

Do your polygons really overlap?  I think it would be ideal if the
shared the nodes.

Matthias

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] When advertising is good

[Nic Roets]

One or two people on the list said that they avoid advertising where
ever they can. I know advertising can be annoying when the same add
appears 10 times in a row, but I just want to explain a few things.

Let's look at the example of a restaurant that is working below
capacity. It can be because they recently opened. It can be because
they are not located on a busy corner. So they have waiters and chefs
not working at peak productivity. They have freshly prepared food
going to waste.

This is a problem that on demand location based advertising can solve,
provided people are willing to accept it in their lives: The
restaurant gets more patrons. Those patrons no longer go to other
restaurants. The other restaurants are now able to serve the remaining
patrons faster.

And the same argument does for most retail and service business.

The great thing about OSM is that we are driving the cost of maps to
$0. If media corporation have annoying ads, people will simply switch.
The media corporation and the advertiser (the restaurant) will now
need to work together to give you the maps at a cost "below 0". My
guess is that it will be in the form of coupons or other specials. "If
you order the OSM special, you get a free softdrink with your burger".

So next time you want to embed maknik in website, consider the
advantages of embedding MapQuest instead.

(And no, I do not have affiliation with MapQuest or any media company).

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Geofabrik Download Server Update

[Frederik Ramm]

Matthias,

Matthias Julius wrote:

But, I need to point out again that theese extracts are not quite as
useful as they could be, IMHO. Unless something has been changed,
ways that cross the bounding polygon are trunkated at the last node
inside the polygon.


I have started to slowly introduce extracts built with the 
--complete-ways option, but not all extracts have that yet. In Europe, 
all sub-country extracts have it but countries don't, so you should be 
able to join two German Laender or two French regions, but you will 
encounter problems when joining a part of Germany with a part of France. 
I'm working on that but even a box with 90 GB of RAM disk has a hard 
time splitting Europe into countries with --complete-ways.


Note that two other preconditions exist for a successful join of 
neighbouring regions. First, the polygons I use for cutting must 
actually overlap. They usually do but every now and then I encounter a 
little bit of no man's land due to polygon simplification. Second, you 
have to use software that properly eliminates the double elements; I'm 
not sure if Osmosis does that.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Vincent Pottier]

Le 03/05/2011 16:54, Pieren a écrit :
On Tue, May 3, 2011 at 3:50 PM, Felix Hartmann 
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


Maybe boundaries are in the database for the renderers only ;-)

Seriously... I can reply.

Don't forget the fundamentals : OSM is a geospatial database 
containing geospatial data. If you are a consumer, use a database 
server with geospatial functions like postGIS (otherwise we don't need 
coordinates in nodes). It's true that it requires some skills and 
learning curves and lazy programmers can always expect that 
contributors will do the job for them...


I'm using boundaries for computing localisation of things.
I never have studied compuning. But i'm able to manage a postGIS 
database, to write queries with spatial functions with jointures, and to 
get some good results. It is not so hard.
And somebody making requests with where clauses such as WHERE 
"addr:country" IS IN (...) is probably able to make a jointure.


IMHO addr:stuff may be necessary in the way that addr:stuff is not 
exactly geolocalisation and can differ from ST_WITHIN results. But it is 
optionnal for only such cases.

--
FrViPofm
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Ed Avis]

M∡rtin Koppenhoefer  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.
> 
>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.

Sorry if I wasn't clear, I was not talking about the use of relations, but 
rather
the idea of tagging separate addr:county, addr:region etc on every individual
object that has an address.  (Perhaps that wasn't what the question was about,
in which case I apologize.)

-- 
Ed Avis 


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[M∡rtin Koppenhoefer]

2011/5/3 Jaak Laineste :
> 2011/5/3 M∡rtin Koppenhoefer :

> 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 editor level to make it less work for the relation,
you will always have the relation as additional work (and you will
have to enter the numbers manually, while I agree that there could be
a minor improvement for pasting:
https://josm.openstreetmap.de/ticket/6300 )


> Point of avoiding redundancy
> (normalization) is to make maintenance easier in long run. How much
> manual work do you need to do if any of the underlying object is
> modified: street names change now and then,
> sometimes whole
> administrative system is reformed and even Europe has countries added
> or merged every decade.


performing a "search" in JOSM you can also quite easily change lots of
objects the same time. I am not totally opposing relations, they are
there and you can use them if you want, it is just that most mappers
don't use them (me included) for housenumbers, because it makes
mapping more complicated without (IMHO) a real benefit, and it is
definitely more complex (bad for less experienced mappers).

cheers,
Martin

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Jaak Laineste]

2011/5/3 M∡rtin Koppenhoefer :
> 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 could be same, or even more extra work, this is
correct (but fixable in editor level). Point of avoiding redundancy
(normalization) is to make maintenance easier in long run. How much
manual work do you need to do if any of the underlying object is
modified: street names change now and then, sometimes whole
administrative system is reformed and even Europe has countries added
or merged every decade.

 OSM database is more or less fully topologically clean (in geometry
terms) and this is something what I really admire from my GIS
background. Any duplicate node is error. It would make sense to follow
same pattern for tags also: invalidate duplicate tag values. At least
in long run.

 With implicit (polygon-derived) spatial relations there is no need
for enduser to maintain most of the the relations: just make sure that
the region polygon is complete. With explicit relation you can always
override spatial relations, this would enable to cover also the "city
address outside of city polygon" case.

-- 
Jaak

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Jo]

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 window
opened.

Adding the roles is an extra step, but it's not a great loss if you would
omit them and I wouldn't be surprised if somebody would add a feature to
JOSM which assigns those roles automatically.

Thanks Martin for changing the spec!

Polyglot

2011/5/3 Kevin Peat 

>
> On 3 May 2011 15:53, M∡rtin Koppenhoefer  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.
>>
>>
> +1
>
> It couldn't be easier (in JOSM at least) to select a bunch of buildings and
> add the tags once. If you use a relation you must create it and add the
> members + tags to it so it is hard to see how that can ever be easier for
> the mapper which is generally what OSM is all about.
>
> Kevin
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Geofabrik Download Server Update

[Matthias Julius]

Kai Krueger  schrieb:

>Altogether, I think those daily country extracts are one of the most
>useful
>"tools" for working with OSM data, so I'd like to send a great thanks
>to
>Geofabrik for providing the resource to offer this valuable service.

I agree.

But, I need to point out again that theese extracts are not quite as useful as 
they could be, IMHO. Unless something has been changed, ways that cross the 
bounding polygon are trunkated at the last node inside the polygon. When two 
neighboring extracts are merged there will be a gap at the border (or worse). 
This makes the extracts unusable if one needs a little bit more than one.  
Merging of two extracts is much easier and resource friendlier than downloading 
the bigger extract and extracting the data from that.

I know it has been stated before that the Geofabrik extracts are as they are to 
maintain backwards compatibility.  One could provide a little tool or osmosis 
filter (if that doesn't exist, yet) that trunkates incomplete ways for tools 
that cannot cope with those on their own.

Matthias



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] [RFC] Draft Requirements and Agreement for OSMF Local Chapters

[Eugene Alvin Villar]

Hello all,

The OSMF Local Chapters Working Group is moving towards building a framework
for the recognition and collaboration with future OSMF Local Chapters all
over the world. Having Local Chapters that involves local OSM contributors
makes sense because OSMF cannot function everywhere and it would be better
to spread OSM's mission and promotion among Local Chapters.

Towards that end, the LCWG has created an initial list of requirements for
potential Local Chapters: http://wiki.openstreetmap.org/
wiki/Foundation/Local_Chapters/Requirements

There is also an initial agreement between a potential Local Chapter and
OSMF: http://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters/Agreement

These are all patterned from the Local Chapters framework of the Wikimedia
Foundation and on points discussed during LCWG online meetings. Please take
note that these are *draft* documents and really needs more input from the
community, especially from Local Chapters-to-be.

If you are interested in commenting on, and discussing these draft documents
or participating in setting up the Local Chapters framework in general,
please do consider joining the local-chapters mailing list which was
specifically set-up to discuss these things:
http://lists.openstreetmap.org/listinfo/local-chapters

You can also find more information about the status of OSMF Local Chapters
over at the wiki:
http://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters

Thanks!

Regards,
Eugene
osm:seav
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Geofabrik Download Server Update

[Kai Krueger]

Frederik Ramm wrote:
> 
> I'd love to but before I start making smaller files for Australia I 
> think I'll do something in the US. 
> 
That would be great!

Currently, I think only Cloudmade are offering state level extracts (much
more managable than the larger extracts) for the US and unfortunately they
are updated very infrequently. The last update being 15th of March. Also
they don't offer the much more efficient osm.pbf format.

Both make the Cloudmade extracts much less useful to work with, so imho it
would be a great help if you could offer the daily extracts for the US as
well.

Altogether, I think those daily country extracts are one of the most useful
"tools" for working with OSM data, so I'd like to send a great thanks to
Geofabrik for providing the resource to offer this valuable service.

Kai


--
View this message in context: 
http://gis.638310.n2.nabble.com/Geofabrik-Download-Server-Update-tp6264407p6327659.html
Sent from the General Discussion mailing list archive at Nabble.com.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Kevin Peat]

On 3 May 2011 15:53, M∡rtin Koppenhoefer  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.
>
>
+1

It couldn't be easier (in JOSM at least) to select a bunch of buildings and
add the tags once. If you use a relation you must create it and add the
members + tags to it so it is hard to see how that can ever be easier for
the mapper which is generally what OSM is all about.

Kevin
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Pieren]

On Tue, May 3, 2011 at 3:50 PM, Felix Hartmann wrote:

> 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
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[M∡rtin Koppenhoefer]

2011/5/3 Ed Avis :
> 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 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.


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.

cheers,
Martin

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Ed Avis]

Felix Hartmann  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 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 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.

-- 
Ed Avis 


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Richard Welty]

On 3 May 2011 15:03:07 +0200, M?rtin Koppenhoefer 
 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 easier it is to enter (and maintain) them, the more
we will get. I suggest to put the information to nodes/polygons for
this reason (and for stability), even if it seems to be a less elegant
(more redundant) approach from a computer science perspective.

i played with associatedStreet relations a little. in a world where
relations are a touch fragile due to underdeveloped support in
the editors, associatedStreet is one of the most fragile.

we have a thicket of address related things (addr:interpolation ways,
associatedStreet, etc.) which have been put together in a somewhat
scattershot way over time. the current system doesn't quite hang
together, some elements are easy to break by accident, and some
things that would be nice to be able to do aren't really possible (e.g.,
including a building outline with an address in an interpolation way.)

if associatedStreet were better supported, it could be a method for
hooking postal codes to houses in the US. in some cases, you'd need
different associatedStreet relations for the two sides of the street
as the sides are on routes served by different post offices.

richard





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Felix Hartmann]

On 03.05.2011 15:05, Pieren wrote:
On Tue, May 3, 2011 at 2:22 PM, Felix Hartmann 
mailto:extremecar...@gmail.com>> wrote:


+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 address 
tags. It's always a good practice to avoid duplicated data in a 
database. It makes only sense if the address cannot be deduced from 
the boundaries (like in US, it seems).
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 space).
Don't forget the fundamentals : OSM is a geospatial database 
containing geospatial data. If you are a consumer, use a database 
server with geospatial functions like postGIS (otherwise we don't need 
coordinates in nodes). It's true that it requires some skills and 
learning curves and lazy programmers can always expect that 
contributors will do the job for them...


Pieren


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Tobias Knerr]

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 trying to bring down all numbers in the "count" column to 1
is /not/ an appropriate strategy for improving our data.

As for house numbers: They are an ubiquitous feature. They should
therefore be easy to tag. A good way to achieve that, in my opinion, is:

1) Add the tags for data that you find out "on the ground" by standing
in front of a house directly to that house. In most places, this
includes the housenumber/-name and street name.

2) Add stuff that you get from official documents or other large-scale
sources as boundaries - e.g. postal city boundaries, postcodes and
country borders.

There is no reason for a building to be part of a relation just because
it has an address. It makes things more complicated than they need to be.

-- Tobias Knerr

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Frederik Ramm]

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 better to redefine it.


Done.

Bye
Frederik

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Jo]

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

2011/5/3 M∡rtin Koppenhoefer 

> 2011/5/3 Jo :
> > 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, addr:postcode and addr:country
> tags.
>
>
> 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 easier it is to enter (and maintain) them, the more
> we will get. I suggest to put the information to nodes/polygons for
> this reason (and for stability), even if it seems to be a less elegant
> (more redundant) approach from a computer science perspective.
>
> cheers,
> Martin
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Pieren]

On Tue, May 3, 2011 at 2:22 PM, Felix Hartmann wrote:

> +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 address tags.
It's always a good practice to avoid duplicated data in a database. It makes
only sense if the address cannot be deduced from the boundaries (like in US,
it seems).
Don't forget the fundamentals : OSM is a geospatial database containing
geospatial data. If you are a consumer, use a database server with
geospatial functions like postGIS (otherwise we don't need coordinates in
nodes). It's true that it requires some skills and learning curves and lazy
programmers can always expect that contributors will do the job for them...

Pieren
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[M∡rtin Koppenhoefer]

2011/5/3 Jo :
> 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, addr:postcode and addr:country tags.


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 easier it is to enter (and maintain) them, the more
we will get. I suggest to put the information to nodes/polygons for
this reason (and for stability), even if it seems to be a less elegant
(more redundant) approach from a computer science perspective.

cheers,
Martin

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Jo]

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, addr:postcode and addr:country tags.

Hence my disagreement with the spec. I did realise that JOSM probably had a
reason to complain about it, ofc. Another problem/argument is that when
streets are split, there will be 2 or more street segments in those
relations anyway.

Cheers,

Polyglot

2011/5/3 M∡rtin Koppenhoefer 

> 2011/5/3 Jo :
> > 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/nodeRoleRecurrence  Comment
> Way street  one The associated street
> Node Area   house   one or more One or more house numbers (use
> "house"
> in tagging but in parsing also allow: "addr:houselink", address )
>
> cheers,
> Martin
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Felix Hartmann]

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 address tags, if OSM database already
has administrative regions for given area? These admin areas already
create implicit relation, which can be used in any application to add
city,country,district,state and other regions. So buildings would have
only addr:street, addr:housenumber (and possibly house:housename and
addr:full tags). Depending on country, addr:postcode could be
geographical also.

Searching a database for a way that surrounds a potentially enormous area (certainly 
enormous in the case of country) when you want to find out "what city/country/... is 
this in" is *far* less efficient than simply looking at the tags.  Plus, Addresses 
are not always as straightforward as you make out, it's not possible to tell which 
administrative areas should be included in an address by simply looking at which ones 
happen to encompass the building.

Bob
___

+1

Look at all current implementations. If the address is not tagged 
completly (country, state, city, street) then programs are lost, and 
boundaries are too often wrong or incomplete or if someone deletes them 
accidentally (or renames them slightly) all data inside the boundary 
wouldn't have an address anymore. Plus it takes a lot of computation 
time, to put boundary information onto objects inside.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[M∡rtin Koppenhoefer]

2011/5/3 Jo :
> 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/nodeRoleRecurrence  Comment
Way street  one The associated street
Node Area   house   one or more One or more house numbers (use "house"
in tagging but in parsing also allow: "addr:houselink", address )

cheers,
Martin

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] talk Digest, Vol 81, Issue 10

[Richard Welty]

On 5/3/11 7:00 AM, Ed Avis  wrote:


Jaak Laineste  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 different from 
the
administrative regions - but even there, the right answer would be to add areas
for postal regions.

for the US, easier said than done. the USPS doesn't publish this data in a
useful form.

the Census Bureau does publish their take on areas corresponding to US
postal codes. don't know how they source it exactly.

in any case, postal codes in the US aren't area directed, they're route
directed, thus putting the codes on ways is a more "correct" model.
even that is potentially risky, but still better than using areas.

richard


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Jo]

What I do to avoid most redundancy, is to create an associatedStreet
relation. So the house only needs a housenumber and maybe a housename and
all the rest of the information is on the relation. (addr:country, addr:city
and addr:postcode). I add more than one street to them though, even if JOSM
complains about that. I only create a different one for the same street if
this street crosses city limits or when a change of postal code occurs.

There is still some redundancy, since postcode, city and country are
repeated in all these relations, but it's already far better, than to have
that information on each and every house.

Cheers,

Polyglot

2011/5/3 Maarten Deen 

> Jaak Laineste  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 I don't
> know how much effort this would cause. If you look at only one node than you
> will have to find the country borders for that node. But where are they? Yes
> there is a (are there more) service in that will give you this, but that
> requires more effort than downloading one node.
>
> As for addr:city, you can not get this from administrative regions in the
> Netherlands. There is no complete admin_level=10 boundary in place. And I'm
> certain it also is not complete in my neighouring countries Germany and
> Belgium, if these boundaries exist there at all. I haven't found them (but I
> only glanced at some areas).
>
> Regards,
> Maarten
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Geofabrik Download Server Update

[Martijn van Exel]

On Tue, May 3, 2011 at 1:19 PM, Richard Mann <
richard.mann.westoxf...@gmail.com> wrote:

> On Tue, May 3, 2011 at 11:55 AM, Martijn van Exel  wrote:
> >
> > Richard:
> > You can consider using osmembrane[1] which is a GUI on top of osmosis. I
> > haven't tested it on Windows but I guess there's no reason it shouldn't
> > work. It makes working with osmosis a much gentler experience ;).
> > [1] http://osmembrane.de/
>
> I'm not sure if downloading a second package is really what I have in
> mind: just a simple howto which uses dos file paths rather than linux
> ones, and tells me which bits are programs (which need to be
> obtained), and which bits are commands to those programs.
>
> I'm sure it's not that difficult to puzzle out, but a few clues would
> make it easier.
>
> Richard
>

If getting the job done and learning about how osmosis works in the process
are among your goals, I guess osmembrane would still be a useful path to
follow.

cutting a bounding box of Port-Au-Prince from a PBF planet file and writing
it out as xml on Windows would be:

C:\osm\osmosis-0.39>bin\osmosis.bat --rb "\osm\planet-haiti-latest.osm.pbf"
--bb left=-72.36 bottom=18.51 right=-72.26 top=18.65 --wx
\osm\planet-portauprince.osm

The only executable you're calling is bin\osmosis.bat (a shell script
wrapper). The rest is described in the wiki:
http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage

Be sure to get 0.39 if you're on windows as per Brett's warning on the main
Osmosis wiki page.

Martijn
-- 
Martijn van Exel
http://about.me/mvexel
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Geofabrik Download Server Update

[Richard Weait]

On Tue, May 3, 2011 at 7:19 AM, Richard Mann
 wrote:
> On Tue, May 3, 2011 at 11:55 AM, Martijn van Exel  wrote:
>>
>> Richard:
>> You can consider using osmembrane[1] which is a GUI on top of osmosis. I
>> haven't tested it on Windows but I guess there's no reason it shouldn't
>> work. It makes working with osmosis a much gentler experience ;).
>> [1] http://osmembrane.de/
>
> I'm not sure if downloading a second package is really what I have in
> mind: just a simple howto which uses dos file paths rather than linux
> ones, and tells me which bits are programs (which need to be
> obtained), and which bits are commands to those programs.
>
> I'm sure it's not that difficult to puzzle out, but a few clues would
> make it easier.

This older tutorial includes using osmosis to extract a bounding box.
http://weait.com/content/make-your-first-map

In the example, the heavy lifting is done here.

./bin/osmosis --read-xml /home/username/planet-090311.osm.gz
--bounding-box left=-94 bottom=38 right=-71.5 top=50 --write-xml
/home/username/GreatLakes.osm.gz

simplifying that by removing paths leaves:

osmosis --read-xml planet-090311.osm.gz --bounding-box left=-94
bottom=38 right=-71.5 top=50 --write-xml GreatLakes.osm.gz

Which is one command with three arguments.

"osmosis" command. This is the only program.

"--read-xml" use an xml-file for input with filename planet-090311.osm.gz

"--bounding-box" take to portion of the data that is within the
bounding box in the four sub-arguments " left=-94 bottom=38
right=-71.5 top=50"

"--write-xml" ... and write it as an xml-file with filename  GreatLakes.osm.gz

With the filepaths removed from the filenames, I expect that your
operating system will only look for, or save, the files in the present
working directory.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Geofabrik Download Server Update

[Richard Mann]

On Tue, May 3, 2011 at 11:55 AM, Martijn van Exel  wrote:
>
> Richard:
> You can consider using osmembrane[1] which is a GUI on top of osmosis. I
> haven't tested it on Windows but I guess there's no reason it shouldn't
> work. It makes working with osmosis a much gentler experience ;).
> [1] http://osmembrane.de/

I'm not sure if downloading a second package is really what I have in
mind: just a simple howto which uses dos file paths rather than linux
ones, and tells me which bits are programs (which need to be
obtained), and which bits are commands to those programs.

I'm sure it's not that difficult to puzzle out, but a few clues would
make it easier.

Richard

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Maarten Deen]

Jaak Laineste  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 I don't 
know how much effort this would cause. If you look at only one node than 
you will have to find the country borders for that node. But where are 
they? Yes there is a (are there more) service in that will give you 
this, but that requires more effort than downloading one node.


As for addr:city, you can not get this from administrative regions in 
the Netherlands. There is no complete admin_level=10 boundary in place. 
And I'm certain it also is not complete in my neighouring countries 
Germany and Belgium, if these boundaries exist there at all. I haven't 
found them (but I only glanced at some areas).


Regards,
Maarten

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Geofabrik Download Server Update

[Frederik Ramm]

Hi,

On 05/03/11 10:48, David Murn wrote:

New Caledonia is not part of Australia.


Bummer. I must have mixed it up with New South Wales or whatever the 
place is called.


I'll check but I think that the NC area should be in the 
"australia+oceania" extract.


Bye
Frederik


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Geofabrik Download Server Update

[Martijn van Exel]

On Tue, May 3, 2011 at 11:56 AM, Richard Mann <
richard.mann.westoxf...@gmail.com> wrote:

> On Tue, May 3, 2011 at 9:11 AM, Frederik Ramm  wrote:
> > I suggest that for the time being you download
> > the 160 MB full Australia file and cut out New Caledonia yourself with
> > Osmosis.
>
> Is there a guide somewhere to using osmosis on Windows. Maybe just a
> simple bounding-box extraction to get us started?
>
> All I find by Googling is "I've {done lots of unspecified stuff and}
> got this horrible error message..." which is hardly encouraging.
>
>
Richard:

You can consider using osmembrane[1] which is a GUI on top of osmosis. I
haven't tested it on Windows but I guess there's no reason it shouldn't
work. It makes working with osmosis a much gentler experience ;).

[1] http://osmembrane.de/
-- 
Martijn van Exel
http://about.me/mvexel
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Nathan Edgars II]

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 Orlando mailing address but am far from Orlando city
limits.

--
View this message in context: 
http://gis.638310.n2.nabble.com/Skip-geographical-redundant-address-tags-tp6326481p6326880.html
Sent from the General Discussion mailing list archive at Nabble.com.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Ed Avis]

Jaak Laineste  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 different from 
the
administrative regions - but even there, the right answer would be to add areas
for postal regions.

In many countries, if a postal code is provided then the county and city are not
needed for postal delivery, although they may still be included in long form
addresses for humans (rather than mail sorters) to get an idea of where it is.

It's my practice to tag addr:housenumber, addr:street and postal_code.
The rest is implicit from the location on the map.  Nominatim, for example, will
work out what region a point is in.  (It doesn't always do a good job, but the
way to fix that is to improve the region areas on the map, not add redundant
addr or is_in tags to every object.)

That said, if you're mapping an area for the first time and you know that a 
house
is 'in' a certain region, but not the exact boundary of that region, feel free 
to
tag it on the house itself.  It can always be improved later.

-- 
Ed Avis 


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Geofabrik Download Server Update

[Richard Mann]

On Tue, May 3, 2011 at 9:11 AM, Frederik Ramm  wrote:
> I suggest that for the time being you download
> the 160 MB full Australia file and cut out New Caledonia yourself with
> Osmosis.

Is there a guide somewhere to using osmosis on Windows. Maybe just a
simple bounding-box extraction to get us started?

All I find by Googling is "I've {done lots of unspecified stuff and}
got this horrible error message..." which is hardly encouraging.

Richard

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Geofabrik Download Server Update

[NopMap]

Thank you for improving the IMHO most important additional service in OSM!

bye
  Nop


--
View this message in context: 
http://gis.638310.n2.nabble.com/Geofabrik-Download-Server-Update-tp6264407p6326736.html
Sent from the General Discussion mailing list archive at Nabble.com.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Geofabrik Download Server Update

[David Murn]

New Caledonia is not part of Australia.  It is approx 2000km east of the
closest point in Australia, about the same distance as New Zealand is.
Does the Australia file (which doesnt seem to be on that linked page at
the moment) cover the entire oceania region?

Maybe its worth looking at putting up smaller filtered extracts (ie.
only highway tagged ways or only amenity tagged features for the US
users, this would reduce the extract size for those who only wish to use
it for navigation or who simply want to keep their POI db up-to-date.

David

On Tue, 2011-05-03 at 10:11 +0200, Frederik Ramm wrote:
> Hi,
> 
> On 05/03/11 07:07, Hendrik Oesterlin wrote:
> > Would it be possible to add New Caledonia in .pbf to
> > http://download.geofabrik.de/osm/australia-oceania/
> 
> I'd love to but before I start making smaller files for Australia I 
> think I'll do something in the US. I suggest that for the time being you 
> download the 160 MB full Australia file and cut out New Caledonia 
> yourself with Osmosis. That may be a small waste of bandwidth, but 
> someone in the southern US currently has to download 1.5 GB if they want 
> to use one of my extracts!
> 
> Bye
> Frederik
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Geofabrik Download Server Update

[Frederik Ramm]

Hi,

On 05/03/11 07:07, Hendrik Oesterlin wrote:

Would it be possible to add New Caledonia in .pbf to
http://download.geofabrik.de/osm/australia-oceania/


I'd love to but before I start making smaller files for Australia I 
think I'll do something in the US. I suggest that for the time being you 
download the 160 MB full Australia file and cut out New Caledonia 
yourself with Osmosis. That may be a small waste of bandwidth, but 
someone in the southern US currently has to download 1.5 GB if they want 
to use one of my extracts!


Bye
Frederik

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Skip geographical (redundant) address tags

[Thomas Davie]

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
> has administrative regions for given area? These admin areas already
> create implicit relation, which can be used in any application to add
> city,country,district,state and other regions. So buildings would have
> only addr:street, addr:housenumber (and possibly house:housename and
> addr:full tags). Depending on country, addr:postcode could be
> geographical also.

Searching a database for a way that surrounds a potentially enormous area 
(certainly enormous in the case of country) when you want to find out "what 
city/country/... is this in" is *far* less efficient than simply looking at the 
tags.  Plus, Addresses are not always as straightforward as you make out, it's 
not possible to tell which administrative areas should be included in an 
address by simply looking at which ones happen to encompass the building.

Bob
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Skip geographical (redundant) address tags

[Jaak Laineste]

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 areas already
create implicit relation, which can be used in any application to add
city,country,district,state and other regions. So buildings would have
only addr:street, addr:housenumber (and possibly house:housename and
addr:full tags). Depending on country, addr:postcode could be
geographical also.

-- 
Jaak

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk