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
(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
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
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
On mercredi 10 octobre 2012, Christian Quest wrote:
Donc...
http://api.openstreetmap.fr/oapi/interpreter?data=LAREQUETE
Pour les area-query, il y a une base MySQL qui vient compléter la base
primaire d'après ce que j'ai lu/compris.
Ha ? beuh ? oulla...
Si c'est bien le cas, j'ai
Bonjour,
Suite à une remarque sur la liste talk-fr indiquant que l'interface xapi
présente sur le serveur http://api.openstreetmap.fr/ n'était pas tout à fait
compatible avec la documentation décrite de XAPI sur le wiki ici :
http://wiki.openstreetmap.org/wiki/Xapi
J'ai jugé bon de réaliser
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
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
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
Vos remarques sont les bienvenues avant que l'on annonce l'existence
de ce live (je prévois ça pour SOTM).
Toutes remarques ?
Alors je vais aller à l'opposé de toutes les éloges lues ici et là :
Mais à quoi ce truc peut-il bien servir ?
Dans la lignée de love-story, voici osm-story, le site ou
On mardi 28 août 2012, Christian Quest wrote:
SUPER !
c'est en effet une super nouvelle, ça ouvre la voie à des mises à jour plus
rapides, des mises à jour de zones réduites.
Y'a plus qu'à tester leur utilisation
Pour ça, il va falloir coder un peu pour que les outils habituels en profitent
+1: les diffs actuels ne sont pas à supprimer, mais à compléter d'où
l'idée de parle d'updates et plus de diff.
Oui, pardon, j'avais bien compris que tu ne parlais pas de leur suppression,
je me suis mal exprimé. La question que je me posais était plutôt qui
devrait être en charge de cette
J'ai vu cette possibilité en voulant installer une overpass API.
Il me semble que cela consiste essentiellement à copier un snapshot des
fichiers d'une overpass à une autre, non ? Il y a un mécanisme plus
perfectionné que ça ?
Je viens de vérifier et en fait, ça consiste juste à ça en effet,
chose d'assez générique pour tous les usages
un polygone de forêt qui ne ferme pas : quelle géométrie ?
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
mon avis.
putty dispose d'un réglage, si tu utilises konsole, pareil, pour le terminal
de gnome, je ne sais pas. Donc ça va dépendre de ton cas
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org
série, pseudo terminaux linux ctrl+alt+F1-F9, etc.)
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
turning it off to
see if speed is increased ?
--
sly (sylvain letuffe)
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
On mercredi 4 juillet 2012, Philippe DAVID wrote:
Ok merci,
il me reste à trouver 1To :)
Suite à la remarque de pieren, je viens de re-vérifier la taille sur disque
avec la fonction SQL : pg_total_relation_size de la base monde (format
osm2pgsql) à laquelle j'ai accès et je trouve 318 Go
On
On jeudi 5 juillet 2012, Philippe DAVID wrote:
Donc sans les tables nominatim (placex, etc..) c'est ça ?
C'est le décompte des tables+indexes correspondants :
planet_osm_(line/nodes/point/polygon/rels/roads/ways)
N'ayant jamais essayé nominatim, je suis bien en peine de donner ce que
rajoute,
Une base osm2pgsql en mode gazetter est plus petite qu'une base dite
osm2pgsql. Mais je ne sais pas dire quel est le rapport entre les
deux.
D'après le mail de F. Ramm, ça ne semble plus être le cas, c'est à dire que la
base nécessaire à un nominatim récent, c'est à dire une version forké du
Merci pour les détails. Je viens de tester les autres, et le .de reste le
plus
réactif que le .ru et le .fr. Donc tant que ça marche, je reste comme ça :-)
C'est très intéressant ce que tu nous dis là (désolé je squate la
conversation)
alors que l'instance sur le .de est une machine
On mercredi 4 juillet 2012, Philippe Verdy wrote:
pasaccordés non lus de
façon cohérente pour servire de guide
Merci philippe, de me faire autant rire
, et en mélangeant aussi des
affirmations (non délimitées), jusqu'au point où on ne savait pas ce
qu'il voulait faire et où était sa
, tu y gagnera
plusieurs journées qui auraient couté plus que les disques ;-) )
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
votre avis ?
oui
Sinon sur du SATA ça veut dire 10 jours à monopoliser les disques si je
comprends bien.
oui (enfin les CPU ne sont pas au repos non plus hein !)
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http
pourrais-tu publier ta
configuration sur la page sus-citée afin que toute la communauté en
bénéficie ?
Je serais moi aussi très intéressé par une publication de la part de philippe
d'un protocol experimental précis et des résultats d'une importation avec
osm2pgsql afin de donner un peu de
Cette vision me paraît un peu angéliste, il ne sera jamais possible
d'obliger tous les contributeurs français à utiliser l'api osm.fr.
Je ne pense pas que ce soit ce que christian suggérait, ou alors j'ai mal
compris.
Autant avoir des caches sur les tuiles afin de soulager les serveurs de
Je me permets une proposition pour cette API, pourquoi ne pas la limiter
au mode lecture seule afin de contourner les soucis de synchro et la
dédier à des usages de consultations intensifs ?
Ben parce que l'on ne pourrait plus s'en servir dans JOSM ou merkator qui est
plus ou moins son seul
ré-importation et comprendre
que les modules ne s'activent plus de la même façon
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
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
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
Le mardi 8 mai 2012 16:56:37, Pieren a écrit :
2012/5/8 sly (sylvain letuffe) li...@letuffe.org:
(une mini contrainte pourrait par exemple être que le point commun ne
puisse être qu'au début ou à la fin d'un chemin du MP, ainsi, la
recherche sera moins longue que passer en revu
finalement c'est la
même figure (même surface, même périmètre, même forme)
non ?
--
sly (sylvain letuffe)
demo3.osm
Description: XML document
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
réparateurs !
Si je peux aider faites moi signe, bien que si j'ai lu correctement, le
problème qui reste ce sont les listes et là j'y connais rien
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org
On vendredi 4 mai 2012, David Gros wrote:
merci pour cette réponse rapide.
Le generate-image.py donne les contours mais aucune données de la base.
generate-image.py est un peu archaïque et ne te parlera pas beaucoup en cas
d'erreur, je te recommande d'utiliser nik2img.py
,
indexes utilisés, etc.)
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
Le mardi 10 avril 2012 21:50:13, Jocelyn Jaubert a écrit :
C'est relancé, et la base osmosis d'osm7 est en train de se mettre à
jour :)
Idem pour la base osm2pgsql de osm7, merci à toi d'avoir adapté les diffs
spécial france.
--
sly (sylvain letuffe
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
On lundi 19 mars 2012, didier2020 wrote:
j'ai enregistré la requete dans un fichier mais quand j'utilise
psql -d osm -U didier -f monfichier.sql
j'ai un message erreur : erreur de syntaxe sur ou près de « SELECT »
Tu peux nous faire passer ton fichier monfichier.sql ?
Peut-être a-t-il été
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;
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
.
L'avantage pour moi d'utiliser mapnik c'est que je l'utilisais déjà pour
générer des bitmap, j'avais donc juste un paramètre à changer pour avoir du
svg, mais en effet, vu la solution simple que tu semble avoir trouvé, ça semble
plus rapide
--
sly (sylvain letuffe
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
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
.
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
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
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
On jeudi 16 février 2012, Ab_fab wrote:
Je ne sais pas trop non plus pour quelles raisons il est jugé nécessaire de
garder ces anciennes références.
Alors virons les ;-)
et mettons à jour convenablement la base de référence du sandre si eux ne le
font pas ;-)
Peut-on virer les lignes
On mardi 7 février 2012, Bruno Cortial wrote:
Salut,
Il y a quelques temps, j'avais proposé 2 scripts python pour améliorer les
fichiers Cléo.
http://lists.openstreetmap.org/pipermail/talk-fr/2011-August/035156.html
Je te propose de passer sur la liste dev-fr histoire de ne pas remplir plus
On mercredi 25 janvier 2012, Jocelyn Jaubert wrote:
Le 25 janvier 2012, sly (sylvain letuffe) a écrit :
La liste des relations qui sont transformées en géométries est
hard-codée dans output-pgsql.c, et sont les suivantes :
type=multipolygon/boundary/road (et j'ai patché la version d'osm7
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
, 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
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
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,
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
Salut,
un rendu tango ...
Moi c'est plutôt salsa, et ça rend bien aussi ;-)
késako ?
Question renderd en pointe je plafone à 15 tuiles (tous les zoom
confondu) par min.
15/minute c'est quand même plutôt faible je trouve, y'a peut-être bien un
problème quelque part.
Moi qui utilise un
)
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
On vendredi 2 décembre 2011, Thomas Clavier wrote:
Jocelyn, sly, ya moyen d'avoir vos astuces de tunning postgres ?
http://osm.tcweb.org en aurais bien besoins :-)
Puis-je proposer de continuer la discussion sur la liste dev-fr (en copie) ?
Un bon tutoriel :
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 :
On vendredi 25 novembre 2011, didier2020 wrote:
bonjour a tous,
juste une petite question:
je voudrais tester/apprendre l'utilisation des base de données postgres
avec osm. Quel est la taille minimum requise pour un extract france ( ou
europe)
( parenthèse :
Comme je le disais en privé,
Chez moi, d'après les stats trouvées dans pgAdmin, l'import France pèse
à peu près 20 GO.
Ha ? c'est moins que moi ça.
Tu utilises le mode --slim ou pas ?
--
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org
(J'ai dû me merdé quelque part, dans mes inscriptions ou autre)
Voilà donc la copie de mon mail lancé sur dev-fr
Quant à çà:
http://c.tile.cartosm.eu/tile/isohypse/15/16895/11787.png, d'ou ça peut
bien venir? Est-ce que le dernier pixel est répété en bord de tuile SRTM?
J'ai le même type
(Merci d'avoir transmis sur dev-fr, c'est bien plus adapté ici)
Test case :
http://analyser.openstreetmap.fr/cgi-bin/index.py?relation=1781467
C'est la pseudo-intersection que tu voudrais qu'elle soit détectée ?
Exact, j'ai pas réussi à la décrire avec des mots mais en gros, le cas
On mercredi 7 septembre 2011, Aurélien FILEZ wrote:
Est-ce que tu as un moyen de savoir si ce qui est généré est exacte et
précis ?
J'ai mais il faut que je bidouille un peu...
Auquel cas j'ouvre une repository sur googlecode qu'on puisse
travailler à plusieurs dessus ? Car ça me semble
On mardi 6 septembre 2011, Aurélien FILEZ wrote:
Merci beaucoup.
Finalement je me suis bricolé un truc à l'arrach' car j'avais besoin des
multipolygons sous format WKT et sous forme de polygon file, d'une relation
quelconque (normal ou super)
Le résultat est ici :
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
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
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
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
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.
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
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
(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
)
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
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
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
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
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
101 - 200 of 211 matches
Mail list logo
