Re: [OSM-dev] Use of OSM API for non-editing third party applications

[Colin Smale]

Now you are confusing authentication with authorisation. 

On 2 August 2019 10:07:19 BST, Tigerfell  wrote:
>Not necessarily, the API calls
>user/details
>(https://wiki.openstreetmap.org/wiki/API_v0.6#Details_of_the_logged-in_user
>)
>and
>user/preferences
>(https://wiki.openstreetmap.org/wiki/API_v0.6#Preferences_of_the_logged-in_user
>)
>are used by some services to provide login and user organisation.
>
>Tigerfell
>
>Aug. 2, 2019, 2:14 a.m. by j...@betra.is:
>
>> Hello Martin.
>>
>> I'm afraid you are confusing two different things.
>>
>> The relevant page for authentication is this one >
>https://wiki.openstreetmap.org/wiki/OAuth
>
>>
>> This is a totally different thing from the editing API.
>>
>> Cheers,
>> Jói
>>
>> 1. ágúst 2019 kl. 21:45, skrifaði "Martin Koppenhoefer" <>
>dieterdre...@gmail.com
>>
>>:
>>  
>>
>>> sent from a phone
>>>
>>> On 1. Aug 2019, at 16:21, Jóhannes Birgir Jensson <>> j...@betra.is
>>> > wrote:
>>>
 I never read anything where it said that OSM-auth was only for
>editing. So I have worked on the assumption that the answer would be
>yes, you can piggyback.

>>>
>>> it’s written here:
>>> https://wiki.openstreetmap.org/wiki/API#Terms_of_use
>
>>>
>>>
>>> Cheers Martin
>>>
>>
>>
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] API Basic Authentication

[Colin Smale]

On 2019-05-30 21:43, Simon Poole wrote:

> See https://github.com/zerebubuth/openstreetmap-cgimap/issues/189 
> 
> Your app should be working again right now as Tom has reverted back to the 
> Rails implemetation, still you should likely be using OAuth to start with.

It is indeed working now. 

I can't see any reference on the wiki
https://wiki.openstreetmap.org/wiki/API_v0.6#URL_.2B_authentication to
the deprecation of Basic Auth on the API. Personally I am happy with
Basic over HTTPS for the moment. As I said this is a private program and
I do not currently intend to publish it to a wider audience. If that
changes then I agree, OAuth would be the way to go. 

Colin___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] API Basic Authentication

[Colin Smale]

Thanks Tom, it is indeed working with the username. 

Colin

On 2019-05-30 21:45, Tom Hughes wrote:

> On 30/05/2019 20:33, Colin Smale wrote:
> 
>> A (private) program I use which accesses the OSM API has stopped working 
>> since the last time I used it, a couple of weeks ago. Read-only calls to the 
>> API, including a (proven correct) Authentication header are now failing with 
>> 401 Unauthorized, with the returned body indicating a problem with the 
>> username/password. The same call without the Authorization header succeeds. 
>> I swear nothing has changed on my side; double-checking the auth header with 
>> Fiddler shows the username/password I expect, and I can still logout/login 
>> using these values (which I haven't changed).
>> 
>> Is there anything going on, or has anything changed on the API, that may be 
>> causing this?
>> 
>> Sample URL: GET on https://api.openstreetmap.org/api/0.6/relation/8465619
>> 
>> I know I can just remove the authentication - it was added for "future use" 
>> anyway - but why has it suddenly broken?
> 
> It's a cgimap bug - previously it just ignored basic authentication
> which was fine because it only handled calls where it was optional.
> 
> The version does do it but has a bug - we have a fix in hand which
> should be rolled out shortly.
> 
> In the meantime try using your username instead of email address and
> make sure you get he case right and it will hopefully work.
> 
> Tom___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

[OSM-dev] API Basic Authentication

[Colin Smale]

A (private) program I use which accesses the OSM API has stopped working
since the last time I used it, a couple of weeks ago. Read-only calls to
the API, including a (proven correct) Authentication header are now
failing with 401 Unauthorized, with the returned body indicating a
problem with the username/password. The same call without the
Authorization header succeeds. I swear nothing has changed on my side;
double-checking the auth header with Fiddler shows the username/password
I expect, and I can still logout/login using these values (which I
haven't changed). 

Is there anything going on, or has anything changed on the API, that may
be causing this? 

Sample URL: GET on
https://api.openstreetmap.org/api/0.6/relation/8465619 

I know I can just remove the authentication - it was added for "future
use" anyway - but why has it suddenly broken? 

Thanks, 

Colin___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Programatic reconstruction of postal code areas

[Colin Smale]

No need to pick nits Martin, you know what I mean. Any lat/lon
associated with a non-geographic postcode is arbitrary and volatile. It
is not needed for delivery purposes - only the code itself is used. It
can be "moved" to some other location, possibly a long distance away, in
a way that is not possible with a normal postcode. In the same way as a
mobile or service (0800 etc) phone number might have a "lat/lon"
representing the current home address of its "user", but that is not the
same as the lat/lon of a fixed line. 

On 2017-03-29 13:32, Martin Koppenhoefer wrote:

> 2017-03-29 12:14 GMT+02:00 Colin Smale <colin.sm...@xs4all.nl>:
> 
>> There are also in some countries "non-geographic postal codes" - things like 
>> reply numbers and PO Boxes.
> 
> they are geographic as well, just that their place is at the post box and not 
> at the owner of that box... ;-)
> 
> Cheers, 
> Martin___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Programatic reconstruction of postal code areas

[Colin Smale]

There are also in some countries "non-geographic postal codes" - things
like reply numbers and PO Boxes. If we are able to filter these out of
the data in some way it may make the job a little easier. 

Although the UK postcodes are not defined as a boundary but as a list of
points, there are several "reverse geocoding" services in the UK which
implicitly will allow you to find the boundary that their algorithm+data
leads to. I have no idea how "accurate" their results are for a random
point, or indeed, how you would measure that accuracy.

//colin 

On 2017-03-29 10:51, Jo wrote:

> I'm in Belgium, so I'm mostly familiar with postal codes here. There are some 
> oddities, but mostly they are not too illogical and it is possible to draw 
> polygons around/in between them. 
> It seems Alex already did this exercise for Austria and Switzerland, so I 
> think it's possible there as well. He'll probably needs to talk to the 
> mailing lists for each country separately to figure out whether there is 
> willingness to define (initial versions of) these boundaries. 
> 
> Polyglot 
> 
> 2017-03-29 10:46 GMT+02:00 Tom Hughes :
> On 29/03/17 09:41, Jo wrote:
> 
> For postal_code boundaries, they will very often follow existing
> boundaries, except where they don't... so I would say it is possible to
> draw them by mostly following the existing admin_boundaries. So now you 
> appear to be talking about the UK which I do know about and which definitely 
> doesn't have boundaries as such.
> 
> Royal Mail as I understand it defines each post code by a list of addresses. 
> They do also provide a centroid point derived from that list but I don't 
> believe they provide any sort of boundary. 
> 
> Tom
> 
> -- 
> Tom Hughes (t...@compton.nu)
> http://compton.nu/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] RFC: OSM data format MIME types

[Colin Smale]

Paul, 

Why the distinction for "historical"? The XML format is the same, isn't
it? The "normal" version just limits itself to a single (the most
recent) version - it a simple subset of "historical". 

Will we need a formal XSD to register these XML formats?

--colin 

On 2016-09-15 05:55, Paul Norman wrote:

> I'm planning on registering MIME types for OSM formats in the vendor tree and 
> could use feedback. If you're unfamiliar with registering MIME types, 
> https://github.com/mapbox/vector-tile-spec/issues/48 is a reasonable overview 
> for a registration that took place with a different format.
> 
> The obvious type for OSM XML is application/vnd.osm+xml, but there are a few 
> unanswered questions
> 
> - Is .osc a different type? I'm think yes. Tools that parse one don't 
> normally accept the other in its place, they normally have different file 
> suffixes, and the top-level XML elements are different.
> 
> - Is osc returned from the server a different type from what is uploaded? I'm 
> inclined towards no. This is more a matter of selection of valid identifiers.
> 
> - Where does history fit in
> 
> I'm inclined towards
> 
> - application/vnd.osm+xml for OSM XML
> 
> - application/vnd.osm.osc+xml for OsmChange XML
> 
> - application/vnd.osm.osh+xml for historical XML
> 
> - application/vnd.osm.osmpbf for current data PBFs. pbf is not a MIME suffix.
> 
> - application/vnd.osm.oshpbf for historical PBFs.
> 
> - application/vnd.osm.o5m
> 
> - application/vnd.osm.o5c
> 
> I'm not sure where to slot changeset data into this. Changeset data can be 
> present in an OSM XML file alongside other data (e.g. with planet dumps) or 
> standalone.
> 
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Simpler binary OSM formats

[Colin Smale]

On 2016-02-08 12:45, Andrew Byrd wrote:

> Hello Benjamin, 
> 
> I was aware of Cap'n Proto, but thanks for pointing out FlatBuffer. I've 
> studied this system and considered how it might be useful for OSM data 
> exchange. Here are my impressions: 
> 
> 1. Each FlatBuffer message does indirection through a table "to allow for 
> format evolution and optional fields". The basic OSM data model is quite 
> stable at this point and to my knowledge evolves only through the 
> introduction of different tag strings. Unlike existing formats, I'd like vex 
> to be extremely simple and non-extensible so developers can easily and 
> completely support reading or writing it. I would hesitate to devote space in 
> every serialized entity to unused extensibility features.

There are discussions going on which may change the underlying data
metamodel. I am thinking of support for polygons/areas as primitive
types and multi-valued keys. Although the model has been stable since
API0.6 it would not be prudent to preclude changes in the future. 

//colin ___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Colin Smale]

 

Can't we have a multi-lingual map by overlaying a base tile with a
transparent text layer in the chosen language? We wouldn't *need* vector
tiles for that, just a bit more storage (bitmap-based text layers should
compress nicely) and clients which can handle the selection and display
of the extra layer, which is pretty commonplace these days anyway). 

--colin 

On 2015-10-30 12:29, Oleksiy Muzalyev wrote: 

> I've heard from the OSM operations team's member at the conference that it is 
> the question of the servers' infrastructure cost.
> 
> But if we have a vector-based map itself language selection, that we could 
> just add tags _name:fr_ or _name: ru_ and have the OSM map of say New York in 
> French or in Russian for tourists. Or map of Siberia in German also for 
> tourists, Middle East in English, etc. without any additions cost on the 
> server side. It is not that difficult to add such multi-language tags. There 
> could be also the map in Basque, Catalan, Kurdish, Scots and other smaller 
> (by number of speakers) languages without any additional cost and without a 
> civil conflict.
> 
> I realize that mobile hardware is not enough advanced for that yet and 
> vector-based technology is only in an development stage.
> 
> brgds
> Oleksiy
> 
> On 30.10.2015 12:06, Maarten Deen wrote: On 2015-10-30 11:53, Oleksiy 
> Muzalyev wrote: 
> One of the advantages of the the vector-based map would be the 
> multilingualism. 
> 
> For instance at the moment the OSM map of the Middle East is basically 
> useless for me as I do not know the Arabic alphabet yet. But as far as 
> I understand and as I heard at the conference the vector-based map 
> would allow the choice of a language of the map itself. 
> I do not see how that can not be solved with png-based tiles. You only have 
> to render the tiles. 
> The method for detecting which tileset/language to show is the same. 
> 
> BTW: it is still not as simple as rendering "in a different language". Then 
> you start rendering a map in English and see names like "Cologne" or 
> "Brussels"  show up on the map. 
> 
> Regards, 
> Maarten 
> 
> ___ 
> dev mailing list 
> dev@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/dev

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev ___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] proposal for mechanical edit reg. power_source + generator:source

[Colin Smale]

 

As there is an indefinite number of data consumers, this is of course
impossible... How would you ever be able to update the tagging if you
have to get consent or acquiescence from every data consumer? What is
your suggestion for sorting out "spaghetti tagging"? How do we ever do
any "refactoring"? 

Sorry for the IT terms, but discussions analogous to this one come up
extremely regularly in the IT business, and the bottom line is that the
bullet needs to be bitten and you have to get your wallet out to sort
things out occasionally. If you don't, your maintenance costs will
sooner or later inexorably spiral out of control. And anyone who says
that this can be prevented by careful planning, doesn't understand how
agile businesses need to be to survive. The costs can be somewhat
mitigated by appropriate architectural decisions (analogous to having
tagging schemes that are e.g. extensible and easily maintainable) but
never eliminated entirely. 

So where do we go from here? Manual review, re-survey and retagging? 

//colin 

On 2015-10-13 10:49, Chris Hill wrote: 

> On 13/10/15 08:56, GerdP wrote: 
> 
>> Hi all,
>> 
>> during the last days I've checked hundreds of places where
>> OSM inspector
>> http://tools.geofabrik.de/osmi/
>> complains about something. Doing that I commented
>> this changeset:
>> http://www.openstreetmap.org/changeset/8335705
>> 
>> As don-vip suggests in his reply I propose a mechanical edit :
>> remove the tag
>> power_source=xyz
>> if the element also has the tag
>> generator:source=xyz
>> 
>> as JOSM complains about the usage of power_source.
>> 
>> If this isn't the right list, please forward it.
> The tag you propose to remove is harmless. How do you know which tags data 
> consumers are using? When you have confirmed with every data consumer that 
> the change you propose will not affect them, or they have agreed to change, 
> then I will agree, until then I disagree with this mechanical edit.
 ___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Building a friendly new editor in JavaScript

[Colin Smale]

Great idea! If it can have a simple way of visualising 
multipolygon/boundary type relations and highlighting anomalies in them, 
it would get a big +100 from me.


Colin

On 13/07/2012 11:31, Richard Fairhurst wrote:

Hi all,

Potlatch is five years old and JOSM is over six years old. Scary, 
isn't it?


Lots has changed in those five years. Browsers now do natively things 
that used to require a plugin - indeed, you might not even have the 
plugin anymore. OSM's changed, too, from a little-known geek project 
to this behemoth of map data used by millions every day.


So we need another editor. Not to replace what we have now: Potlatch 
fulfils the intermediate editor role and JOSM fulfils the advanced 
editor role very nicely. What we don't have, yet, is a simple, 
friendly editor as a welcoming way into OSM.


I thought I'd start writing one.

So: iD. Pure JavaScript, using the Dojo toolkit (which is really nice).

It's at a really early stage of development. It doesn't save anything 
yet, nor do any tagging, nor even let you delete things - that's how 
early it is. After all, it'll be much better if the collective brains 
of OSM and elsewhere apply themselves to the challenge, rather than 
just me sitting in a room in Charlbury.


Fancy getting involved?

Here's the project page:
http://www.geowiki.com/

And here's the source:
https://github.com/systemed/iD

Throw questions at me (on dev@) or just get started and hack away. 
Between us we can build something really good.


cheers
Richard



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




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

Re: [OSM-dev] Building a friendly new editor in JavaScript

[Colin Smale]

On 13/07/2012 15:51, Viesturs Zarins wrote:
My idea is to hide the relations altogether and automatically deduce 
areas from geometry.
The user would just click on enclosed area and assign tags to it, 
never caring about the technical details.


In landuse mode all the lines should form areas and all crossings are 
errors in data.
If there are no crossings, areas can be figured out pretty easily. 
Depending on geometry they will be saved as simple ways or 
multipolygons..

I think I'll make some mock-ups to start a more technical discussion.

There are so many broken relations out there, I can't imagine any 
automated fix-up being good enough to let loose on the whole of OSM. 
They will need to be assessed by a human, and possibly fixed by a human 
as well. There are tools like the Relation Analyzer[1] which will show 
you one relation at a time, but you need to enter the ID or search for 
them individually. Something which will allow multipolygons (especially 
admin boundaries) within the current display area to be visualised would 
make life a lot easier. Just open a view on your area of interest, and 
click the button to show me the boundaries. Correctly formed relations 
highlighted in green, broken relations (requiring human intervention) 
highlighted in red. Then select a broken one, see the constituent parts, 
and fix the problem.


But I entirely support any thought that prevention is better than cure; 
making it easy to build new MPs correctly, and maybe making it 
impossible to save broken MPs, would prevent the problem of bad data 
getting worse.


The Dutch have a good expression for the current situation: mopping up 
with the tap still running. Step one is to turn off the tap.


Colin

[1] http://ra.osmsurround.org/index


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

Re: [OSM-dev] (Multi)Polygon handling

[Colin Smale]

On 13/07/2012 16:05, Jochen Topf wrote:

On Fri, Jul 13, 2012 at 03:24:47PM +0200, Even Rouault wrote:

That sounds reasonable. But we need to agree on what is valid and what is
treated as invalid. In the testsuite of closed ways that I commited to
github I defined an output for every case, but I'm not sure if the inputs
are valid. My guess would be:
1) Definitely valid

OK


2) valid

Why do you need to reverse the winding order ? I thought that the WKT convention

Winding order should not be changed IMHO. It might mean something in specific
cases, who knowns? It could be an optional feature.

Jochen
Is there not a problem with making winding order significant, as a 
particular way can be shared between adjacent polygons? For example the 
common boundary between two admin areas. For the polygon on the left, 
the points within the way must be ordered north-to-south (for clockwise 
winding) whereas the polygon on the right will require south-to-north.


Colin


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

[OSM-dev] Max nodes in a way?

[Colin Smale]

Hi,

I am working on some gigantic GPX files with hundreds of thousands of 
points, representing admin boundary polygons. I'm sure these huge ways 
will break something or cause performance to be dreadful, so I am 
planning to split the enormous polygons into a number of ways and tie 
them together in a relation.


What's a reasonable value to assume for the maximum number of nodes in a 
way? 1000? 1?


Colin

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

[OSM-dev] Potlatch 2.3 Make Circular going crazy

[Colin Smale]

Hi,

Yesterday and today I was adjusting (enlarging) a couple of existing 
roundabouts by dragging some nodes outwards and clicking on the Make 
circular button. It seemed to work as usual, until I looked more 
closely... It had created some kind of extra colinear ways around the 
roundabout with far too many nodes. I ended up deleting the roundabout 
and recreating it. I put it down to one of those things at the time, 
but it just happened again in a completely different session on a 
different roundabout...


The build is coming up as 2.3-79-g633f140.

Anyone else seeing this?

Thanks,
Colin


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

Re: [OSM-dev] Potlatch2 Merge Ways broken?

[Colin Smale]

On 27/06/2011 08:01, Richard Fairhurst wrote:

Colin Smale wrote:

Thanks for the confirmation, I'm looking forward to the fix!

Should be live now.


Fixed! Thanks a lot.

Colin


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

[OSM-dev] Potlatch2 Merge Ways broken?

[Colin Smale]

Hi,

Since yesterday I have been noticing strange behaviour from Potlatch2 
when merging 3 or more ways. I am actually coalescing successive 
segments of one road into a single way.


The last few nodes of the merged way seem to end up in a random order. 
Undo doesn't work either, so the only options are to abandon the 
changeset, or to fix up the damage by hand. It only seems to occur when 
merging 3 or more ways - when merging exactly 2 ways it seems to work OK.


Can anybody else confirm this? The Help information says it's Version: 
2.2 Build: 2.2-6-gaa899ca.


Colin


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

Re: [OSM-dev] Potlatch2 Merge Ways broken?

[Colin Smale]

On 26/06/2011 23:33, Richard Fairhurst wrote:

Colin Smale wrote:

Since yesterday I have been noticing strange behaviour from
Potlatch2 when merging 3 or more ways.

Yes, it's broken. Fix committed a couple of days ago and will be deployed
real soon now.

Thanks for the confirmation, I'm looking forward to the fix!

Colin


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

[OSM-dev] Potlatch2 - ways all unrecognised?

[Colin Smale]

Hi,

I'm not sure if this is the best place to ask this; if not please accept 
my apologies...


I have been using Potlatch2 for several weeks now without serious 
hassles. Since yesterday however it can't recognise a way. What I mean 
by that, is that when you select a way (of any type) it always says it's 
not recognised and doesn't show the information appropriate to the 
type of way. If I switch to Advanced view, all the tags are there, but 
I don't dare to edit anything. Nodes (e.g. POIs) work fine.


I have tried different browsers (I normally use Chrome; I tried Firefox 
and IE8), restarted my computer and cleared out browser caches.


Has anyone got any idea what I can do to fix this?

Thanks in advance for any tips!

Colin

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

Re: [OSM-dev] Potlatch2 - ways all unrecognised?

[Colin Smale]

It is fixed now, in v25177. Thanks!

Colin

On 29/01/2011 12:21, Richard Fairhurst wrote:

Colin Smale wrote:

I have been using Potlatch2 for several weeks now without serious
hassles. Since yesterday however it can't recognise a way.

We think there's a bug and are looking into it.

cheers
Richard





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

[OSM-dev] Extracting national boundaries

[Colin Smale]

 Hi,

I am trying to extract national boundaries from OSM and it's proving 
more difficult than I anticipated.


What I would like to end up with, is a collection of complex polygons 
(inner and outer rings including enclaves/exclaves), one for each 
country. I thought I should be able to do that by getting all relations 
with type=boundary, admin_level=2. Using XAPI I got a large file which 
contains some of the information, but as some national boundaries seem 
to be implemented using subrelations and subsubrelations etc I now find 
I will have to query the database for each subrelation individually and 
drill down successively until I have all the ways I need. But that looks 
as if it will give me large numbers of internal borders between 
lower-level admin units as well, and it will be an enormous job to 
stitch everything together and discard the internal borders.


For many countries there is a simple relation for the national boundary, 
referencing a number of ways, which I can concatenate to produce the 
complete outer boundary. But France and Slovakia for example don't seem 
to have a single relation as a starting point.


I can't imagine I am the first person to want to do this. Has anyone got 
any tips? Or maybe even a ready-made data set?


National boundaries don't change all that often, but it does happen from 
time to time, so it would be nice if this could be repeatable in the future.


Thanks in advance for any help you can give!

Regards,
Colin

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

Re: [OSM-dev] Extracting national boundaries

[Colin Smale]

 Pieren, you are right, it looks like I should be able to work with the 
data for France.


Specific countries (with the top level relations) that are definitely 
giving challenges right now are:

*Slovakia (#14296)
*Luxembourg (#28711)
*Czech Republic (#51684)
*Switzerland (#51701)
*Lithuania (#72596)
*Spain (#92863)

Current roadblock is that the country relation contains subrelations 
which contain subrelations. I dived a bit deeper into Spain. It has a 
top-level relation #92863 at admin_level=2 which includes relation 
#349042 (Basque Country) at admin_level=4. This contains a whole load of 
ways, plus some subrelations e.g. #349011 (Araba / Álava) which is at 
admin_level=6. This, in turn, contains many relations for individual 
towns such as #339581 (Kuartango) at admin_level=8 which thankfully only 
contains ways. So in order to build up the outer boundary of Spain, I 
have to query for the boundary of every single town in Spain, and then 
collect all the ways together and work out which ones are internal (not 
relevant to the outer border which is what I am trying to get to) 
including handling enclaves and exclaves. This nesting of administrative 
areas works OK for the area, as the area covered by a country is equal 
to the sum of the areas covered by its consituent parts, but it's a 
right PITA if you are trying to work with the boundaries as lines and 
polygons.


Thanks again for any assistance!

Colin

On 30/08/2010 11:30, Pieren wrote:
On Mon, Aug 30, 2010 at 11:05 AM, Colin Smale colin.sm...@xs4all.nl 
mailto:colin.sm...@xs4all.nl wrote:


But France and Slovakia for example don't seem to have a single
relation as a starting point.


There is the one for France (land_area):
http://www.openstreetmap.org/browse/relation/11980

It's a relation of relations otherwise the amount of ways is simply 
too big to manage (it's the sum of all municipalities external 
boundaries - shared with other countries or coastline).


Pieren


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