I think I finished my script that imports NASA SRTM3 data into Postgres.
http://sprovoost.nl/2008/05/31/import-nasa-srtm3-data-into-postgres/
Kind regards,
Sjors
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman
Thomas Wood schreef:
>> type=node ref=1 role=from
>> type=node ref=2 role=at
>> type=node ref=1 role=at
>> type=node ref=3 role=to
> If by ref you mean node id, then yes, the second 1 is not allowed.
> The API used to throw an unhandled exception back at you (500) if you
> did it because of an ind
On Fri, May 30, 2008 at 9:21 PM, Stefan de Konink <[EMAIL PROTECTED]> wrote:
> Second question:
>
> Are there currently any constraints on relations members based on:
>
> 1) Sequence
>
> and/or
>
> 2) 'Reuse'
>
>
> So would it be allowed to do:
>
> type=node ref=1 role=from
> type=node ref=2 role=a
Second question:
Are there currently any constraints on relations members based on:
1) Sequence
and/or
2) 'Reuse'
So would it be allowed to do:
type=node ref=1 role=from
type=node ref=2 role=at
type=node ref=1 role=at
type=node ref=3 role=to
Or is the second 1 not allowed?
Next to this; ca
Stefan de Konink wrote:
> Reading the DTD it seems to be unbound to have multiple tagn having the
> same key. Is this allowed? (JOSM doesn't allow it, but is it a constraint?)
Currently the API allows duplicate tags, but we don't believe any of the
editors do. We plan to remove support for them
Stefan de Konink wrote:
>Sent: 30 May 2008 9:04 PM
>To: Openstreetmap Dev list
>Subject: [OSM-dev] Datamodel tag/key constraint
>
>Hi,
>
>
>Reading the DTD it seems to be unbound to have multiple tagn having the
>same key. Is this allowed? (JOSM doesn't allow it, but is it a constraint?)
>
As far
Hi,
Reading the DTD it seems to be unbound to have multiple tagn having the
same key. Is this allowed? (JOSM doesn't allow it, but is it a constraint?)
Stefan
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailm
Alex Wilson schreef:
> Should have an example C++ api serving from an apache module online soon.
I guess it is a good thing that there is development going on for this
API thingie :) If you have a demo too, please make a wiki.
My demo can be found here:
http://wiki.openstreetmap.org/index.php/C
Am Freitag, den 30.05.2008, 13:37 +0200 schrieb Steven te Brinke:
> SELECT *
> FROM current_war_tags
> WHERE id IN (
> SELECT *
> FROM current_ways
> WHERE tile IN (...)
>AND latitude BETWEEN ... AND ...
>AND longitude BETWEEN ... AND ...
> )
> ORDER BY id;
>
> However,
I previous post pointed me to the page on the wiki:
http://wiki.openstreetmap.org/index.php/TIGER_to_OSM_Attribute_Map
which has most of the Tiger CFCC code conversions. But it is missing
the Classification D, E, F, and H. Is there info for these classifications?
Specifically, I am interested i
In message <[EMAIL PROTECTED]>
Steven te Brinke <[EMAIL PROTECTED]> wrote:
> The second query uses a join only to select the correct values, not
> because you really want to join the tables. I think that you can achieve
> the same by a query like this:
>
> SELECT *
> FROM current_war_tag
> Consider a way from 0°, -189.999° to 0°, 180°. that is, in our current
> datamodel, a way that's roughly 40,000 km long.
No. In the datamodel, it's just a way between two nodes.
The nodes are defined in lat, lon, effectively in spherical co-ordinates,
hence them being angles. (ignoring not
Hi Steven,
Thanks for the suggestion. I think it would work nicely on a more
sophisticated db, but in my limited experience - MySQL is pretty dumb about
running subqueries and you can end up with O(n2) run time. So it's better to
stay with dumb joins unless OSM moves to something a little more
hea
Tom Evans schrieb:
Our data-model does not support earth as a sphere.
Uh? The data model supports it fine as far as I can see.
Yes, virtually all the tools don't, because it isn't a problem so far (and is
harder...). But they could be improved in the future and the data model would
be f
The second query uses a join only to select the correct values, not
because you really want to join the tables. I think that you can achieve
the same by a query like this:
SELECT *
FROM current_war_tags
WHERE id IN (
SELECT *
FROM current_ways
WHERE tile IN (...)
AND latitude
Thanks Tom. I'll have a play with the various alternatives - and keep the
code flexible enough to allow them to be swapped without much fuss.
Alex
2008/5/30 Tom Hughes <[EMAIL PROTECTED]>:
> In message <[EMAIL PROTECTED]>
> Alex Wilson <[EMAIL PROTECTED]> wrote:
>
> > Ah. good point - a
In message <[EMAIL PROTECTED]>
Alex Wilson <[EMAIL PROTECTED]> wrote:
> Ah. good point - a sensible third way. Apologies for missing it, I'm a
> relative SQL novice. However, if you fetch the tags along with the ways
> using a join, given that there are potentially many tags per way - coul
Ah. good point - a sensible third way. Apologies for missing it, I'm a
relative SQL novice. However, if you fetch the tags along with the ways
using a join, given that there are potentially many tags per way - couldn't
you end up with considerable duplication of the way data in the query
result? I
In message <[EMAIL PROTECTED]>
Alex Wilson <[EMAIL PROTECTED]> wrote:
> I'm taking the printf method below - except streaming out using the apache
> module interface rather than stdout. I'm also streaming as much stuff from
> the db as possible (nodes, ways, . However I believe for the map
I'm taking the printf method below - except streaming out using the apache
module interface rather than stdout. I'm also streaming as much stuff from
the db as possible (nodes, ways, . However I believe for the map query
there's a trade-off between local process memory usage and minimising db
queri
20 matches
Mail list logo
