:
- 10,000,000 builings (from a single house to church to towers to many others)
- composed roughly from 4 to ~50 nodes
Thoughts are welcome
--
sly
Sylvain Letuffe li...@letuffe.org
qui suis-je : http://slyserv.dyndns.org
___
dev mailing list
dev
adding one more understanding difficulty to begginers.
The problem is not that simple, tests areas will be built in order to find
what drawbacks we could hit.
--
sly
Sylvain Letuffe li...@letuffe.org
qui suis-je : http://slyserv.dyndns.org
___
dev
Sylvain Letuffe li...@letuffe.org
qui suis-je : http://slyserv.dyndns.org
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
files I have are over 2Mo.
I could down-scale the quality... but... that's dommage
--
sly
Sylvain Letuffe li...@letuffe.org
qui suis-je : http://slyserv.dyndns.org
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo
.html
dev might well be a better place to discuss this, that code could be removed
if I'm the only one to use it (or pushed into a style's switch)
--
sly
Sylvain Letuffe li...@letuffe.org
qui suis-je : http://slyserv.dyndns.org
___
dev mailing list
.
--
sly
Sylvain Letuffe li...@letuffe.org
qui suis-je : http://slyserv.dyndns.org
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Either from wget or from JOSM those requests now only get a 500 interval
server error.
Thanks to whoever resolve the issue, it restart working yesterday afternoon.
It might or might not be a who, maybe just the end of a load congestion.
--
sly
Sylvain Letuffe li...@letuffe.org
qui suis-je
in advance every thing up to zoom 18 by
reading :
http://wiki.openstreetmap.org/wiki/Mod_tile
http://wiki.openstreetmap.org/wiki/Slippy_Map
--
sly
Sylvain Letuffe li...@letuffe.org
qui suis-je : http://slyserv.dyndns.org
___
dev mailing list
dev
or use it.
Has anyone started work to support them in osm2pgsql ? or in any other tool ?
PS: maybe other solutions for the database could be better ?
--
sly
Sylvain Letuffe li...@letuffe.org
qui suis-je : http://slyserv.dyndns.org
___
dev mailing
=0 +k=1.0 +units=m +nadgri...@null +no_defs +over
)
Then everything should be fine.
Access restrictions at postgres level ?
Turn on the logs of postgres and try some custom basic queries to see if the
data is here.
select * from planet_osm_roads limit 1;
--
sly
Sylvain Letuffe li
,900913)
On Thu, Mar 19, 2009 at 7:02 PM, sly (sylvain letuffe)
li...@letuffe.org wrote:
My osm tables use Google Mercartor (SRID= 900913) What is mapnik
expecting? 3395 ?
No it's good. If you've used osm2pgsql to populate the db, and if you use
a
copy of the osm.xml
( starting
planners to make the good choice in absence of evidence OR construct a post
osm data feeder that will make those country specific things explicit.
--
sly
Sylvain Letuffe li...@letuffe.org
qui suis-je : http://slyserv.dyndns.org
___
dev mailing list
buffer[1024];
char buffer[1024];
char osmtype[24];
char tag[24];
char datatype[24];
Recompiling osm2pgsql might help, if that limit of 24 is not present elsewhere
--
sly
Sylvain Letuffe li...@letuffe.org
qui suis-je : http://slyserv.dyndns.org
it is advised to keep in sync with delayed minute diff :
http://planet.openstreetmap.org/minute-slow/
instead ?
Or is there any work around that I, as a client to the system, can do ?
--
sly
Sylvain Letuffe li...@letuffe.org
qui suis-je : http://slyserv.dyndns.org
to be usable for bulk upload
tests ? and if yes, who could create an account for us ?
--
sly
Sylvain Letuffe li...@letuffe.org
qui suis-je : http://slyserv.dyndns.org
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org
Sylvain Letuffe li...@letuffe.org
qui suis-je : http://slyserv.dyndns.org
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
there was some rendering and the
dev db looks empty.
Sorry for the useless noise.
Every thing is working
--
sly
Sylvain Letuffe li...@letuffe.org
qui suis-je : http://slyserv.dyndns.org
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org
)
The linestring representation of the relation is not there, but it's polygon
version in planet_osm_polygon is not updated
Thanks for reading, and/or pointing me to the good place
--
sly
Sylvain Letuffe li...@letuffe.org
qui suis-je : http://slyserv.dyndns.org
?xml version=1.0 encoding=UTF-8?
osmChange
(Spherical Mercator)
Setting up table: planet_osm_point
Adding new column IN to planet_osm_point
ALTER TABLE planet_osm_point ADD COLUMN IN text;
failed: ERROR: column IN of relation planet_osm_point already exists
Error occurred, cleaning up
--
sly
Sylvain Letuffe li...@letuffe.org
qui suis-je
On mercredi 27 juillet 2011, NopMap wrote:
You know about the throttling of download speed in mod_tile, I guess.
Well no, because I don't use mod_tile, but that is a good idea, instead of
blocking completly the ability to download, reducing/limiting the hit rate
per minute per IP might be a
From the download pattern. Humans have a linear distribution of tile
requests with most in zoom 14 and 15. Tile scrapers show an exponential
increase with higher zoom levels.
whaoo ! That shows you've gone far in tile scrapers activity analyse and it
soon logical about normal human behavior.
Can you try if using the switch --number-processes=1? That should disable
any parallelisation and make it more or less the same as before. (Although
there is a slight difference in transaction handling)
It's x2 faster with --number-processes=4 instead of 1 but still far from older
version
Kai has suggested to me changing configuration of postgresql like this:
fsync = off
synchronous_commit = off
And this worked like a charm, now I'm getting significantly faster
imports compared to old config and old osm2pgsql.
Whaoo !
It just work (and very well)
--
sly
qui suis-je :
Hi,
On jeudi 15 décembre 2011, Frederik Ramm wrote:
But: Anyone who really wants to, and has the resources to, can set up a
full database today, feed it with minutely diffs through Osmosis
That is true, but there are no solutions for bellow minute synchronisation
(like near real time
Re-Hi,
Exemples of bad requests are :
http://www.openstreetmap.org/api/0.6/relation/1403916/full
That looks like something I need to investigate. My guess is that it is
hitting the timeout but it should be reporting that better.
I guess you guessed it well, there is just too much (to
Hi,
We're working
hard on getting the relevant hardware in place to start trialling this
out, but it's a big project.
Many thanks for the insight
The original topic was about replication for rendering, so a comment
on that
Whooops, I haven't read that thread far enough in the past to
Hi,
Following :
http://lists.openstreetmap.org/pipermail/dev/2011-December/023945.html
http://lists.openstreetmap.org/pipermail/dev/2011-December/023981.html
I've set up a read load balancer/proxy to the main OSM API
Better than a thousand words, here it is :
http://beta.letuffe.org/api/
It
, no multi-request, a quick test on 100 shows me in 3 day it's
over
I'm willing to do it myself and share the result if it doesn't look too much a
over load for the API
== head buried in the sand to avoid the sword ==
--
sly (sylvain letuffe)
___
dev
It looks like osm2pgsql does not merge route members into selfstanding
geometry objects. Therefore the following sample queries will send routes
as a short segments.
In case you are interested, I have the patch to solve the case, but it's
really easy to implement in osm.
Find
// Split long
commented out (on purpose)
aren't you missing this line ?
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
.
Reading that thread, I remembered that I don't need type=route either, I've
commented that part of osm2pgsql but the speed gain is hardly noticeable (if
at all)
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http
I know that there are precedents, but I am highly averse to coding
specific relation types into osm2pgsql.
So do I, as you mentionned below, the problem is not osm2pgsql specific, but
will need work in every tool to maintain support for ever changing relation's
way of tagging, and every new
their member ways are just added to the planet_osm_lines
table, they are not even concatenated.
Sven
Are you sure ? I might be mistaken, but thought they were concatenated and
then split again if in exces of 1°x1°
(line ~1080 in output-pgsql.c )
I haven't fully checked what does the
On vendredi 2 mars 2012, Peter Körner wrote:
By defining algorithms to work with relations in one place and mapping
relation-types to that algorithms in another place.
The idea looks sexy, but relations have so many different construction that
you will probably end with as much algorithms as
type=boundary is much the same as type=multipolygon. I have always argued
that only type=multipolygon should be used for boundary=administrative. One
down.
I do agree with you on the fact that boundaries could or should be tagged
as type=multipolygon, but that is not the case in the
are affected by runing :
select id from planet_osm_way where pending which should run in less than a
second if index is well used.
To solve the problem post import, we did re-index and ran analyse
reindex index planet_osm_ways_idx;
analyse;
--
sly (sylvain letuffe
gis= explain select id from planet_osm_ways where pending;
Index Scan using planet_osm_ways_idx on planet_osm_ways
(cost=0.00..916513.78 rows=43724 width=4)
This is what I've got after a re-index :
gis=# explain select id from planet_osm_ways where pending;
Hi,
[1] They'll include changes by the background cleaning script so the
diffs will be larger than usual.
This is interesting, is there any blog post/wiki page explaning this ?
(I read : http://blog.osmfoundation.org/2012/04/04/api-read-write-returns/ )
Sorry if I missed it, but is the
Hi,
I've asked this question on the tagging list, but I guess this wasn't the best
place to talk about it since it involves a question of convertion ability for
algorithms to go from OSM's definition of multipolygons (MP) to the OGC
simple feature MP entity.
I consider the wiki, as a source
I chose a bounding box that is only slightly larger than Hungary - so
that the content doesn't stop at the national border. while importing
hungary.osm.bz2 is very fast (less then an hour), importing this
bounding box via europe.osm.bz2 takes very very long
Weird, do you mean your import
turning it off to
see if speed is increased ?
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
and only a coincidence. But those augmented diffs might be another
alternative to keep a regional db up to date.
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
was refering to (just a different url)
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
On mercredi 5 septembre 2012, Stéphane Henriod wrote:
Dear all
Dear stéphane,
My problem is that, despite the *osm2pgsql -b* option, it seems that my
bounding box is ignored and the full diff file is added to my database, As
a consequence, the database is growing very quickly and includes
On mercredi 5 septembre 2012, Stéphane Henriod wrote:
Hi again
yo, again,
Does this mean that I can simply empty them regularly?
You can, but then applying diffs won't be possible at all. Those table are not
only used to reduce memory usage of the first import, but also to hold all
data to
But it looks like I have a problem now...
1. I need to keep the tables ways, rels and nodes because of the diff
updates
2. Those 3 tables will continue growing up with each new diff, until I
reach the storage capacity of the server
The only solution I see
is to increase the
I will end up
with the full planet (as every single node in OSM might be modified one day
or the other...)
Well, My guess is that it will take a lng time, so long before that you
might need to re-import your extract for whatever fail delete, style change,
software update, and so on. Thus
I just tried another hack, but feel it's going nowhere:
1. Export all from the database to an osm file = full.osm
That's not possible using an osm2pgsql schema with existing tools I know.
Although a bit heavy I thought it would work... But apparently, Osmosis
cannot read the PostGIS
hi,
but is it a bug? or am I missing the good reason why there is this factor
100?
I searched the source code to find the reason why there is a x100 on
coordinate, but couldn't find where it's done.
But my guess is that for performance reasons, the field to store x/y was
chosen to be an
Building such a meta
platform is not an easy task because bugs are much more than just
popup markers on the map - bugs can also be a way, or a collection of
ways, or a convex hull around a broken polygon; a good platform will
also allow the user to flag those bugs which are false
updates and things seams to
work as expected. Let's see how it performs in case of network hickups
note : I have a strange issue with all objects's timestamp, they seam to be
shifted by -1 hour
--
sly (sylvain letuffe)
___
dev mailing list
dev
(http://www.opengeospatial.org/standards/sfs)
with the notable exception of touching inner rings (see below).
'''
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
the final
idea on talk (backed up by definition ranging from clear mathish un-
understandable by common people definition to clear examples with graphics) ?
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http
Le dimanche 14 octobre 2012 15:48:08, sly (sylvain letuffe) a écrit :
I'll come back later with examples as a graphic is far easier to understand
than fix font ASCII art
Here is some food for thoughts :
http://wiki.openstreetmap.org/wiki/Relation:multipolygon/validity
Feel free to add other
to be valid either.
I also have boundary examples on request to express it is needed, but we can
either build those cases with that :
http://wiki.openstreetmap.org/wiki/File:Multipolygon_Illustration_self_touching_on_one_point.svg
--
sly (sylvain letuffe
with
the OGC
In the case
http://wiki.openstreetmap.org/wiki/Relation:multipolygon/validity#F_-
_Polygon_self_touching_on_one_node
A valid OGC can still be constructed as you described it (one outer and one
inner touching on one point)
--
sly (sylvain letuffe
-st_makevalid/
It can be wrongly interpreted as a single
ring polygon with self-intersection. However, it could be transformed into
a valid OGC MultiPolygon with two parts ABF and BCDE.
correct.
--
sly (sylvain letuffe)
___
dev mailing list
dev
hi,
Perhaps a useless idea from my side. I would also like to hire you for an
hour or two for quick reading some other OGC specifications for me.
I'm far from an expert for that ;-)
Perhaps you mean that the OSM wiki page I've created should be made more
explicit for developers (or another
And something else: Somebody recently started a collection of mp testcases
and put it in a github repository. I forgot where that was but maybe
somebody
can dig that up and join in that work.
That would be interesting to include this to my wiki page to display real
example cases in the
On vendredi 12 octobre 2012, Tom MacWright wrote:
Hey all (or, well, those subscribed to dev@ - my flamewar shields are at
50% so I'm not risking an email to talk),
This only is my opinion, but wishlists shouldn't be reduced to those
subscribed to dev@
Maybe start on dev, but I think a wiki
I guess it is pretty expensive to do topology checks
in the main OSM database triggered automatically every time when relations
are saved.
I think this is the best way to do it, don't allow crap in the db so that you
don't have to correct it later.
But it might be unreasonable for
On lundi 15 octobre 2012, Pedro Larroy wrote:
I don't see why
editing and refining a page is bad.
Because in this case, this page is the documentation of how to do things in
the OSM db, and if by refining you mean changing the way to do things, then
people will map according to what they've
On lundi 15 octobre 2012, Tom MacWright wrote:
Hey Sly,
Hi tom,
Yes and no. Everything is a trade between being totally open (announce it
on IRC and see what the crowd thinks!) and being totally productive (hole
up and just do it until you're done and then realize it's duplicated
effort).
is just going to spend my time)
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
- there are no restrictions on what you should work on. the data
is open, the software is open, and you can work on whatever is
interesting to you.
I know that. The question is more : On what should the MapBox team work on,
and who should decide what is this what
--
sly (sylvain letuffe
Hi,
That said, let's talk less about talking and your personal suspicions and
more about actual substance;
Is that substance :
http://wiki.openstreetmap.org/wiki/API_v0.7
?
aka un-derail this thread.
Got it, sorry.
--
sly (sylvain letuffe
, please do.
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
On jeudi 18 octobre 2012, Paweł Paprota wrote:
It's great that you are driving this. One potential use of such list
would be defining the Top Ten Tasks list.
A list with that name allready exists, therefore I don't want to say that this
list would define the TTT
However, any admin is of
On jeudi 18 octobre 2012, Kai Krueger wrote:
I would suggest putting it on help.openstreetmap.org rather than on the
wiki.
For sure, a wiki for voting purpose is to be classified as one of the worst
tool to do it, but it was easy to copy the first wishes from the same syntax.
Using help
or at least any approved with a certain threshold of uses.
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Hi,
Le mercredi 07 novembre 2012 17:15:10, Matt Amos a écrit :
(...)
Is there any plan to provide something like augmented changeset diff ?
(ie : diffs with the content of the changeset in osmchange format when closed
in addition to the changeset itself )
--
sly (sylvain letuffe
test
case to show the problem ?
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
probably won't get
what you want : the geometry
this is the command line I use for the import:
osm2pgsql -d oam --bbox 16,45,23,49 -s -C 2048 --hstore-all -K -v -G -v
-m -S oam.style dump.osm
Looks good (beside one extra -v)
--
sly (sylvain letuffe
, is the relation itself in PostGIS
I ran a test and I can confirm as well that without type tag, the relation
isn't imported into _rels
However, whatever the value is like type=toto is enough so that the relation
makes it's way to the _rels table, but not to the _polygon table.
--
sly (sylvain letuffe
I would like the server to answer in these 3 seconds, but with
the tiles and HTTP 200 and not with an 404.
I tried several settings, such as
ModTileRequestTimeout 500
ModTileMissingRequestTimeout 500
ModTileMaxLoadMissing 50
but still the same 404. Is there a possibility for find out why
#Backgound_map_with_the_most_possible_objects
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
always correct because you can tag how you want are not what they expect)
+the data layers isn't available as a JOSM slippy map selector (and the plugin
download as you pan and zoom isn't as functional because it can hardly work
on low zooms)
--
sly (sylvain letuffe
?
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
On mercredi 19 décembre 2012, Svavar Kjarrval wrote:
Hi.
Hi,
I also tried to stick '
/dev/null' and ' /dev/null 21' at the end of the osm2pgsql command
within the shellscript with no effect.
This works for me, I suggest you check again for syntax errors,
And try :
* * * * *
/Comparatif_des_formats_de_base_de_donn%C3%A9es#Comparatif
osmosis schema takes 500Go of disk space for the planet file of 2012-09-15
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
, I heard there was ongoing work to provide a file's
timestamp in the pbf file itselft, is that operationnal ? or planned to be ?
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
] timestamp=2013-01-02T01:10:14Z
That is indeed a very usefull trick to know.
Thanks.
I'll update http://wiki.openstreetmap.org/wiki/Planet
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Le vendredi 11 janvier 2013 15:33:10, Peter Körner a écrit :
Am 11.01.2013 15:17, schrieb sly (sylvain letuffe):
bzcat planet-130102.osm.bz2 | head -n 2
Or without downloading the whole file:
curl http://planet.openstreetmap.org/planet/planet-latest.osm.bz2 |
bzcat | head -n 2
Sure
,
I just find it really optimistic, and I would bet that the discussion part
about what model to choose would be, if not faster, at least much less risky
for the contributors discovering their version of software X suddenly broke
without warning...
--
sly (sylvain letuffe
On jeudi 28 mars 2013, Simone Cortesi wrote:
On Thu, Mar 28, 2013 at 5:52 PM, Kai Krueger kakrue...@gmail.com wrote:
Renderd can do that just fine as well. Currently there is a hard coded
limit
of 10 in the source code of renderd, but that would be easy enough to
change.
can you point
alternative with xapi
or overpass API by replacing api.openstreetmap.org by api.openstreetmap.fr
http://wiki.openstreetmap.org/wiki/Servers/api.openstreetmap.fr
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http
the fr instance won't change your problem...
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
On vendredi 21 juin 2013, Lynn W. Deffenbaugh (Mr) wrote:
18GB for the planet and my postgresql database is about 260GB after
importing the planet into it. Add space for rendered tiles, and it's
pretty demanding.
If you've only got a single magnetic spindle for the 500GB, you might
find
a http proxy local to your hosting.
--
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
(sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
On mardi 18 février 2014, JB wrote:
Hello,
Hello,
If not, where can the note DB be bulk-downloaded for the planet or by
country/bbox/poly?
A quick search led me to :
https://github.com/iandees/planet-notes-dump
Which mean than Ian work(ed|s) on such a project, I guess it isn't operational
On mercredi 2 juillet 2014, Ilya Zverev wrote:
and since diffs are only available for the whole planet
FYI, that isn't true anymore :
http://wiki.openstreetmap.org/wiki/Planet.osm/diffs#Regionally_limited_diffs
Geofabrik is providing daily diffs for any subregion you can imagine
and french
On jeudi 3 juillet 2014, Ilya Zverev wrote:
If, with comments above, this
script is still not the best way to have regional minutely updates,
please point me to an alternative.
I wasn't saying that what you did is or isn't the best way (best beeing
relative to a need) to have regional diffs,
SELECT Y(ST_AsText(ST_Transform(way, 4326))),
X(ST_AsText(ST_Transform(way, 4326))),
Distance(way, (SELECT way FROM planet_osm_point WHERE
osm_id=582505865))::int,
amenity || ' ' || name, 'icon.png', '16,16', '0,0'
FROM planet_osm_point P WHERE (amenity ILIKE 'res%' OR amenity ILIKE
Il paraît que vous avez un outils permettant de créer un polygon à partir de
super-relations comme c'est le cas pour les bordures françaises..
Comment s'appelle cet outils ?
A priori, mais j'avais testé une vielle version il y a 2 ans de ça, cet outil
devrait faire l'affaire :
Ah tiens, j'en apprends tous les jours sur les fichiers présents sur
osm1.crans.org :)
J'utilise de mon côté un autre script, que j'ai mis temporairement là:
http://osm1.crans.org/~jocelyn/
Ah tiens, j'en découvre moi aussi !
J'en rêvais d'un comme ça, capable de sortir du svg, du gpx, du
J'ai essayé les deux scripts pour créer le polygon de la France et :
(...)
Je ne les ais pas encore utilisé, mais sachant qu'ils ont été plus ou moins
écrit dans ce but, je suis surpris que ça ne marche pas.
Est-ce que ce n'est pas tout simplement car la france actuellement, ne forme
pas un
On vendredi 2 septembre 2011, Aurélien FILEZ wrote:
Y a-t-il une notion d'ordre à respecter ou c'est normal ce genre de cas ?
C'est normal, une relation n'a pas l'obligation d'avoir ses membres ordonnés.
C'est cependant plus pratique pour les cartographe quand c'est le cas pour
repérer des
On vendredi 2 septembre 2011, Aurélien FILEZ wrote:
Hi !
Est-ce que c'est pareil pour les relations simples ?
C'est vrai quel que soit le type d'élément membres d'une relation (noeud, way
ou relation)
L'API osm les restituant dans l'ordre dans lequel ils ont été envoyés mais ne
réalisant
l'espagne à monaco)
et
France (côte méditerranéenne de monaco à l'Italie)
ou
2) on accepte que cette relation ne forme pas qu'une seule ligne brisée mais 2
PS: comme ce questionnement n'est pas uniquement technique, j'envoi en copie
sur la liste talk-fr
--
sly (sylvain letuffe
1 - 100 of 211 matches
Mail list logo
