Re: [OSM-talk-fr] bug de rendu sur les lignes de terrain de sport sur le rendu osmfr

[Christian Quest]

J'ai corrigé la requête... étonnant que les mises à jour du serveur aient
provoqué cet effet de bord.

Les nouvelles tuiles générées sont OK, par contre, pour les existantes, je
vais lancer un recalcul général mais il va prendre du temps.

Le ven. 10 août 2018 à 10:32, David Crochet  a
écrit :

> Bonjour
>
> Les rendus des terrains de sport semblent incohérent (rotation de 90° ):
>
>
> http://tile.openstreetmap.fr/?zoom=18&lat=49.17863&lon=-0.37182&layers=B00FF
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] bug de rendu sur les lignes de terrain de sport sur le rendu osmfr

[Eric Brosselin - Osm]

Bonjour,

Je l'ai signalé le 18 juillet dernier à Christian Quest (cf ci-dessous)

Le problème est apparu suite à la relance du serveur du rendu FR.


Oups... je regarde d'où ça vient, car les requêtes SQL n'ont pas 
changé et la feuille de style non plus.


Sûrement un effet de bord inattendu des nombreuses mises à jour récentes !



Le 18/07/2018 à 13:56, Eric Brosselin - Osm a écrit :

Le 18/07/2018 à 00:31, Christian Quest a écrit :
C'est bien normale et on n'a rien à cacher, même nos pétouilles et 
cagades :)


Il me semble qu'il y a un problème avec les terrains de sports

Voir >>> https://framapic.org/nBQk6DArfag4/PopHrAb631dc.jpg



-- Christian Quest - OpenStreetMap France




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] bug de rendu sur les lignes de terrain de sport sur le rendu osmfr

[Philippe Verdy]

Je confirme et c'est partout. Et pas un problème de rafraîchissement ;
certainement un bogue dans la formule de calcul d'angle (ou un changement
inattendu dans une fonction mathématique utilisée)

http://tile.openstreetmap.fr/?zoom=17&lat=48.11792&lon=-1.64677&layers=B00

Si c'était une inversion inattendue des coordonnées x/y ce ne serait pas
une rotation de 90° mais une symétrie par rapport à la diagonale et on
aurait un rendu "presque" correct sur:

http://tile.openstreetmap.fr/?zoom=17&lat=48.11792&lon=-1.64677&layers=B00

où les terrains sont orientés pratiquement sur les diagonales
(contrairement au premier exemple où les terrains sont orientés
pratiquement sur les directions cardinales).


Le ven. 10 août 2018 à 10:32, David Crochet  a
écrit :

> Bonjour
>
> Les rendus des terrains de sport semblent incohérent (rotation de 90° ):
>
>
> http://tile.openstreetmap.fr/?zoom=18&lat=49.17863&lon=-0.37182&layers=B00FF
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] bug de rendu sur les lignes de terrain de sport sur le rendu osmfr

[David Crochet]

Bonjour

Les rendus des terrains de sport semblent incohérent (rotation de 90° ):

http://tile.openstreetmap.fr/?zoom=18&lat=49.17863&lon=-0.37182&layers=B00FF

Cordialement

--
David Crochet


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Xavier Cremaschi]

Ça j'avais tenté, aucun objet n'est en cause on dirait.

Le 08/06/2015 11:51, Bruno Cortial a écrit :

Bonjour,
Dans ce genre de cas on peut utiliser la nouvelle fonction disponible 
sur osm.org  afin d'identifier l'objet en cause : 
"Requête sur les objets" symbolisé par un "?" à droite.


Cela permet de renvoyer les "objets englobants" l'endroit cliqué, et 
aurait sans pu identifié le building (?) en cause.


A+
Bruno

Le 8 juin 2015 11:45, Xavier Cremaschi > a écrit :


Ok, merci pour ta réponse.



Le 08/06/2015 11:36, Sylvain Maillard a écrit :

Il s'agit bien d'un bug lié au rendu, sans doute un problème lors
de l'import/mise à jour des données.

Le problème semble corrigé, lorsque l'on force la régénération
des tuiles celles-ci apparaissent correctement. Une des solutions
est de passer toutes les tuiles concernées en /dirty pour forcer
le recalcul, ou sinon d'attendre une peu qu'elles soient
recalculées automatiquement


Sylvain


Le 8 juin 2015 11:31, Xavier Cremaschi mailto:omega.xav...@gmail.com>> a écrit :

Bonjour,
il y a un bug de rendu ici :
http://www.openstreetmap.org/#map=19/48.95067/4.36876
uniquement au niveau de zoom maximum.
Une grande zone rectangulaire marron apparait. Une idée de ce
qui peut être fait pour corriger ça ? Qui faut-il contacter ?

Merci :)
Xavier.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr




___
Talk-fr mailing list
Talk-fr@openstreetmap.org  
https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Bruno Cortial]

Bonjour,
Dans ce genre de cas on peut utiliser la nouvelle fonction disponible sur
osm.org afin d'identifier l'objet en cause : "Requête sur les objets"
symbolisé par un "?" à droite.

Cela permet de renvoyer les "objets englobants" l'endroit cliqué, et aurait
sans pu identifié le building (?) en cause.

A+
Bruno

Le 8 juin 2015 11:45, Xavier Cremaschi  a écrit :

>  Ok, merci pour ta réponse.
>
>
>
> Le 08/06/2015 11:36, Sylvain Maillard a écrit :
>
>  Il s'agit bien d'un bug lié au rendu, sans doute un problème lors de
> l'import/mise à jour des données.
>
>  Le problème semble corrigé, lorsque l'on force la régénération des tuiles
> celles-ci apparaissent correctement. Une des solutions est de passer toutes
> les tuiles concernées en /dirty pour forcer le recalcul, ou sinon
> d'attendre une peu qu'elles soient recalculées automatiquement
>
>
>  Sylvain
>
>
> Le 8 juin 2015 11:31, Xavier Cremaschi  a écrit :
>
>> Bonjour,
>> il y a un bug de rendu ici :
>> http://www.openstreetmap.org/#map=19/48.95067/4.36876
>> uniquement au niveau de zoom maximum.
>> Une grande zone rectangulaire marron apparait. Une idée de ce qui peut
>> être fait pour corriger ça ? Qui faut-il contacter ?
>>
>> Merci :)
>> Xavier.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Xavier Cremaschi]

Ok, merci pour ta réponse.


Le 08/06/2015 11:36, Sylvain Maillard a écrit :
Il s'agit bien d'un bug lié au rendu, sans doute un problème lors de 
l'import/mise à jour des données.


Le problème semble corrigé, lorsque l'on force la régénération des 
tuiles celles-ci apparaissent correctement. Une des solutions est de 
passer toutes les tuiles concernées en /dirty pour forcer le recalcul, 
ou sinon d'attendre une peu qu'elles soient recalculées automatiquement



Sylvain


Le 8 juin 2015 11:31, Xavier Cremaschi > a écrit :


Bonjour,
il y a un bug de rendu ici :
http://www.openstreetmap.org/#map=19/48.95067/4.36876
uniquement au niveau de zoom maximum.
Une grande zone rectangulaire marron apparait. Une idée de ce qui
peut être fait pour corriger ça ? Qui faut-il contacter ?

Merci :)
Xavier.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Sylvain Maillard]

Il s'agit bien d'un bug lié au rendu, sans doute un problème lors de
l'import/mise à jour des données.

Le problème semble corrigé, lorsque l'on force la régénération des tuiles
celles-ci apparaissent correctement. Une des solutions est de passer toutes
les tuiles concernées en /dirty pour forcer le recalcul, ou sinon
d'attendre une peu qu'elles soient recalculées automatiquement


Sylvain


Le 8 juin 2015 11:31, Xavier Cremaschi  a écrit :

> Bonjour,
> il y a un bug de rendu ici :
> http://www.openstreetmap.org/#map=19/48.95067/4.36876
> uniquement au niveau de zoom maximum.
> Une grande zone rectangulaire marron apparait. Une idée de ce qui peut
> être fait pour corriger ça ? Qui faut-il contacter ?
>
> Merci :)
> Xavier.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Bug de rendu

[Xavier Cremaschi]

Bonjour,
il y a un bug de rendu ici :
http://www.openstreetmap.org/#map=19/48.95067/4.36876
uniquement au niveau de zoom maximum.
Une grande zone rectangulaire marron apparait. Une idée de ce qui peut 
être fait pour corriger ça ? Qui faut-il contacter ?


Merci :)
Xavier.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Yves]

Le consensus pour le routage va faire l'unanimite des devs: faut pas rever. 
Voire avec 2 ans de RAM en plus, peut-etre...
Par contre, rien n'empeche d'afficher tout les highways avec area=yes comme des 
surfaces.
Yves


Nicolas Moyroud  a écrit :

Merci Christian pour la vérification. Du coup je suis circonspect sur la 
conduite à tenir. Retour à ma première solution avec signalement du problème de 
rendu mapnik ? Quoi qu'il arrive je vais attendre un meilleur consensus avant 
de corriger tous mes autres area.

Nicolas


Le 23/03/2012 18:17, Christian Quest a écrit : 

Visiblement OSRM s'en sort bien avec des highway en surface. J'ai regardé les 
places en questions. 

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

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Nicolas Moyroud]

  
  
Merci Christian pour la vérification. Du coup je suis circonspect
sur la conduite à tenir. Retour à ma première solution avec
signalement du problème de rendu mapnik ? Quoi qu'il arrive je vais
attendre un meilleur consensus avant de corriger tous mes autres
area.

Nicolas


Le 23/03/2012 18:17, Christian Quest a écrit :

  Visiblement OSRM s'en sort bien avec des highway en surface.

J'ai regardé les places en questions.




  


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

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Christian Quest]

Visiblement OSRM s'en sort bien avec des highway en surface.

J'ai regardé les places en questions.

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

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Nicolas Moyroud]

  
  
Je ne pensais pas déclencher un tel débat "philisophique" avec mon
message ! Mais c'est intéressant de voir les avis différents sur la
question  :-) 
Dans le cas des area dans mon secteur de mapping, il s'agit
quasi-exclusivement de simples élargissements de la voie avec une
zone accessible en tous points aux voitures (quelquefois il y a des
places de parking dans le coins). J'ai donc taggué un area=yes avec
un highway=residential et un linéaire en highway=tertiary qui
traverse.
J'avoue que je préférais moi aussi la solution "connexion à un
polygone" parce que maintenant je trouve ça très moche et que ça
donne vraiment un mélange étrange. Mais bon après si c'est la seule
méthode qui permet aux algorithmes de routage de s'y retrouver...
Pieren tu dis que cela ne mérite pas l'utilisation d'un tag area
parce que ce ne sont pas des places, n'empêche que sur le cadastre
c'est bien nommé "Place de l'église" ou "Plan du Barrie". Donc
officiellement je pense que c'est bien considéré comme des places !

Nicolas


Le 23/03/2012 10:32, Pieren a écrit :

  
Euh, tout de même pas... Les moteurs de rendu ont des problèmes
spécifiques et les logiciels de routage en ont d'autres. Mais comme tu
dis, les logiciels de routage peuvent s'adresser à differents profiles
et les area's en "highway=pedestrian" sont très courants et devraient
donc être supportés par les routeurs en mode "piétons" de toute façon.
Mais modéliser une place en ajoutant le fillaire à l'intérieur, c'est
vraiment "tagguer pour le logiciel de routage" alors que
techniquement, rien n'empêche de connecter les voies à un polygone. Si
physiquement, la place est sans voie de circulation ni restriction de
direction, on devrait la modéliser comme tel. Les routeurs peuvent
facilement traiter ce cas en réduisant le polygone "highway=*" +
"area=yes" en simple noeud dans un pré-traitement.
Le fait que Mapnik ne supporte pas ces cas ne devrait pas influencer
notre jugement sur la modélisation.
Mais les exemples cités dans le premier message ne sont pasdes
"places" mais simplement des voies qui s'élargissent à l'approche
d'une intersection. Cela ne mérite pas amha l'utilisation d'un
polygone avec "area=yes".
L'autre exemple de la place Grenette à Grenoble est encore différent
puisque la place est piétonne (pedestrian) mais est traversée par une
voie de circulation auto. Dans ce cas-là, symboliser la voie de
circulation par un fillaire propre est logique puisque de nature
différente que celle de la place.

Pieren




  


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

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Jean-Marc Liotier]

On 23/03/2012 14:47, Florian LAINEZ wrote:
Une highway=pedestrian traverse la place, elle même notée comme une 
area pedestrian. Cela me semble logique puisque lorsque l'on veut 
traverser la place, le plus court chemin est de suivre la 
highway=pedestrian.
Donc au delà de l'interprétation du logiciel de calcul d'itinéraire, 
c'est une indication utile pour connaitre le chemin le plus rapide 
pour traverser la place.
- Si l'aire est un espace entièrement ouvert, alors il est inutile 
d'indiquer un chemin pour la traverser : le cheminement est évident.
- Si des obstacles restreignent le cheminement, pourquoi ne pas les 
indiquer ? Il serait alors inutile d'indiquer un chemin pour traverser 
l'aire.
- Si l'aire est suffisamment compliquée pour qu'il soit nécessaire 
d'indiquer des chemins, est-ce bien une aire ? Ne serait-ce pas plutôt 
des chemins avec des aires à côté ?


La règle séparant la modélisation sous forme d'aire et la modélisation 
sous forme de chemins ne sera jamais parfaitement définie. La 
modélisation mixte a certainement également des cas d'application... 
Mais je crois qu'ils sont moins nombreux que tu sembles le penser.



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

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Florian LAINEZ]

Mouais je ne suis qu'à moitié convaincu par vos arguments, notamment
lorsque l'on voit physiquement un balisage de highway.

Voici ce que j'ai fait dans un petit village :
http://www.openstreetmap.org/?lat=46.083379&lon=6.726798&zoom=18&layers=M
La départementale qui est physiquement séparée de la place piétonne par des
plots est bien mappée.
Une highway=pedestrian traverse la place, elle même notée comme une area
pedestrian. Cela me semble logique puisque lorsque l'on veut traverser la
place, le plus court chemin est de suivre la highway=pedestrian.
Donc au delà de l'interprétation du logiciel de calcul d'itinéraire, c'est
une indication utile pour connaitre le chemin le plus rapide pour traverser
la place. Donc pour moi, c'est une info qui est utile et devrait être
mappée.

Le 23 mars 2012 12:19, rldhont  a écrit :

> Le 23/03/2012 11:41, Jean-Marc Liotier a écrit :
>
>  On 23/03/2012 10:32, Pieren wrote:
>>
>>> techniquement, rien n'empêche de connecter les voies à un polygone. Si
>>> physiquement, la place est sans voie de circulation ni restriction de
>>> direction, on devrait la modéliser comme tel. Les routeurs peuvent
>>> facilement traiter ce cas en réduisant le polygone "highway=*" + "area=yes"
>>> en simple noeud dans un pré-traitement.
>>>
>> Oui pour le calcul de connectivité, mais pour les indications de
>> navigation il lui faudra calculer la distance et le cap entre l'entrée sur
>> la surface et la sortie de la surface - ce qui pourra d'ailleurs donner des
>> indications erronées dans le cas d'une surface concave (pour laquelle un
>> algorithme plus évolué proposera au moins un changement de cap à
>> l'intérieur de la surface).
>>
>> Je suis ravi que cette conversation ait lieu - je me suis souvent posé
>> cette question pour les zones piétonnes. J'hésitais mais je suis maintenant
>> renforcé dans ma conviction que la correction et la simplicité du modèle
>> doivent être nos guides - les routeurs suivront !
>>
>
> Les routeurs suivront car c'est aux développeurs de configurer leur réseau
> correctement pour tenir compte de aires et pas aux contributeurs de le
> faire.
>
> D'ailleurs je croyait que l'on tagger et représentait la réalité pas pour
> une application ou plusieurs (rendu, routing, 3D, etc)
>
>
>
>>
>> __**_
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.**org/listinfo/talk-fr
>>
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>



-- 

*Florian Lainez*
http://twitter.com/overflorian
http://www.nouslesgeeks.fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[rldhont]

Le 23/03/2012 11:41, Jean-Marc Liotier a écrit :

On 23/03/2012 10:32, Pieren wrote:
techniquement, rien n'empêche de connecter les voies à un polygone. 
Si physiquement, la place est sans voie de circulation ni restriction 
de direction, on devrait la modéliser comme tel. Les routeurs peuvent 
facilement traiter ce cas en réduisant le polygone "highway=*" + 
"area=yes" en simple noeud dans un pré-traitement.
Oui pour le calcul de connectivité, mais pour les indications de 
navigation il lui faudra calculer la distance et le cap entre l'entrée 
sur la surface et la sortie de la surface - ce qui pourra d'ailleurs 
donner des indications erronées dans le cas d'une surface concave 
(pour laquelle un algorithme plus évolué proposera au moins un 
changement de cap à l'intérieur de la surface).


Je suis ravi que cette conversation ait lieu - je me suis souvent posé 
cette question pour les zones piétonnes. J'hésitais mais je suis 
maintenant renforcé dans ma conviction que la correction et la 
simplicité du modèle doivent être nos guides - les routeurs suivront !


Les routeurs suivront car c'est aux développeurs de configurer leur 
réseau correctement pour tenir compte de aires et pas aux contributeurs 
de le faire.


D'ailleurs je croyait que l'on tagger et représentait la réalité pas 
pour une application ou plusieurs (rendu, routing, 3D, etc)





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



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

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Jean-Marc Liotier]

On 23/03/2012 10:32, Pieren wrote:
techniquement, rien n'empêche de connecter les voies à un polygone. Si 
physiquement, la place est sans voie de circulation ni restriction de 
direction, on devrait la modéliser comme tel. Les routeurs peuvent 
facilement traiter ce cas en réduisant le polygone "highway=*" + 
"area=yes" en simple noeud dans un pré-traitement.
Oui pour le calcul de connectivité, mais pour les indications de 
navigation il lui faudra calculer la distance et le cap entre l'entrée 
sur la surface et la sortie de la surface - ce qui pourra d'ailleurs 
donner des indications erronées dans le cas d'une surface concave (pour 
laquelle un algorithme plus évolué proposera au moins un changement de 
cap à l'intérieur de la surface).


Je suis ravi que cette conversation ait lieu - je me suis souvent posé 
cette question pour les zones piétonnes. J'hésitais mais je suis 
maintenant renforcé dans ma conviction que la correction et la 
simplicité du modèle doivent être nos guides - les routeurs suivront !



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

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[sly (sylvain letuffe)]

hello,

> Pieren :
> Mais modéliser une place en ajoutant le fillaire à l'intérieur, c'est
> vraiment "tagguer pour le logiciel de routage" alors que
> techniquement, rien n'empêche de connecter les voies à un polygone. 

Je vais finir moi aussi par me poser des questions, mais j'ai bien 
l'impression que je suis à nouveau d'accord avec Pieren.

Contrairement à une bonne partie des réponses, comme hélène je m'interroge sur 
les raisons qui nous poussent à "tagguer pour le routage" (c'est à dire 
mettre du filaire et du surfacique superposés)

Pour ma part, quand le cas se présente, je superpose en effet surface et 
filaire mais reste dans ma bouche un goût de "mal fait" où j'ai la sensation 
de faire le boulot en double, faire un truc un peu crade et, clairement, 
bidouiller pour que le routage marche.

Le truc, c'est que je ne connais aucun logiciel de routage qui puisse prendre 
en compte le routage sur une surface. Donc, bien que je ne souhaite tagguer 
ni pour un rendu en particulier, ni pour un logiciel de routage en 
particulier, là j'hésite, car tagguer dans un mode qui me semblerait "propre" 
au niveau modélisation s'avérerait utilisable nulle part.

bref, je ne sais pas trop quoi faire entre modèle parfait et pragmatisme 
utilitaire, mais la réponse ne me semble pas évidente 

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Pieren]

2012/3/23 Eric Sibert :

> Le routage est UN rendu...

Euh, tout de même pas... Les moteurs de rendu ont des problèmes
spécifiques et les logiciels de routage en ont d'autres. Mais comme tu
dis, les logiciels de routage peuvent s'adresser à differents profiles
et les area's en "highway=pedestrian" sont très courants et devraient
donc être supportés par les routeurs en mode "piétons" de toute façon.
Mais modéliser une place en ajoutant le fillaire à l'intérieur, c'est
vraiment "tagguer pour le logiciel de routage" alors que
techniquement, rien n'empêche de connecter les voies à un polygone. Si
physiquement, la place est sans voie de circulation ni restriction de
direction, on devrait la modéliser comme tel. Les routeurs peuvent
facilement traiter ce cas en réduisant le polygone "highway=*" +
"area=yes" en simple noeud dans un pré-traitement.
Le fait que Mapnik ne supporte pas ces cas ne devrait pas influencer
notre jugement sur la modélisation.
Mais les exemples cités dans le premier message ne sont pasdes
"places" mais simplement des voies qui s'élargissent à l'approche
d'une intersection. Cela ne mérite pas amha l'utilisation d'un
polygone avec "area=yes".
L'autre exemple de la place Grenette à Grenoble est encore différent
puisque la place est piétonne (pedestrian) mais est traversée par une
voie de circulation auto. Dans ce cas-là, symboliser la voie de
circulation par un fillaire propre est logique puisque de nature
différente que celle de la place.

Pieren

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

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Eric Sibert]

- on ne taggue pas pour le rendu (leit-motif récurrent sur cette liste),


On ne taggue pas pour UN rendu particulier ;-)
On taggue pour tous les rendus, passés, présents et à venir!!!


-par contre il semble bien vu de tagguer pour le routage ;


Le routage est UN rendu... et encore, il y le routage voiture,  
camping-car, vélo, piéton, chaise roulante, aveugle...


Eric


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

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Christian Quest]

Toutafé !

Surtout que le rendu peut très bien donner l'impression qu'il y a
connexion, alors qu'il n'y en a pas.
C'est d'ailleurs une erreur très courante des nouveaux contributeurs
qui tracent une route qui se termine à quelques metres d'une autre. Ca
ne se verra pas sur le rendu.

OSM Inspector a une couche qui montre ça très bien.


Le 22 mars 2012 23:24, Ab_fab  a écrit :
> On ne tague pas pour le rendu, mais on connecte pour le routage !
>
> Le 22 mars 2012 23:16, Hélène PETIT  a écrit :
>
>> Le 22/03/2012 16:09, Christian Quest a écrit :
>>
>>> C'est vraiment pas une bonne idée car un logiciel de calcul
>>> d'itinéraire a bien du mal à faire quelque chose de ces données.
>>
>>
>> - on ne taggue pas pour le rendu (leit-motif récurrent sur cette liste),
>> -par contre il semble bien vu de tagguer pour le routage ;
>>
>> Je pige pas encore tout, mais ça va viendre, faut pas que je me désespère.
>>
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> --
> ab_fab
> "Il n'y a pas de pas perdus"
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Ab_fab]

On ne tague pas pour le rendu, mais on
connectepour le routage !

Le 22 mars 2012 23:16, Hélène PETIT  a écrit :

> Le 22/03/2012 16:09, Christian Quest a écrit :
>
>  C'est vraiment pas une bonne idée car un logiciel de calcul
>> d'itinéraire a bien du mal à faire quelque chose de ces données.
>>
>
> - on ne taggue pas pour le rendu (leit-motif récurrent sur cette liste),
> -par contre il semble bien vu de tagguer pour le routage ;
>
> Je pige pas encore tout, mais ça va viendre, faut pas que je me désespère.
>
>
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>



-- 
ab_fab 
"Il n'y a pas de pas perdus"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Hélène PETIT]

Le 22/03/2012 16:09, Christian Quest a écrit :

C'est vraiment pas une bonne idée car un logiciel de calcul
d'itinéraire a bien du mal à faire quelque chose de ces données.


- on ne taggue pas pour le rendu (leit-motif récurrent sur cette liste),
-par contre il semble bien vu de tagguer pour le routage ;

Je pige pas encore tout, mais ça va viendre, faut pas que je me désespère.



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

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Romain MEHUT]

Est-ce que vous pourriez donner un lien vers un endroit montrant une route
traversant une "area", je ne comprends pas bien comment cela doit être
représenté?

Romain

Le 22 mars 2012 17:31, Christian Quest  a écrit :

> Effectivement, cette page du wiki n'est pas bien claire et
> contradictoire avec celle décrivant highway=tertiary
>
> Le seul cas habituel ou un chemin fermé peut être taggué
> highway=tertiary c'est le rond-point, mais il a aussi un
> junction=roundabout et pas de area=yes
>
> Un peu plus bas dans la même page est indiqué: "Note: There is
> currently no clear agreement on how highway tag values other than
> pedestrian should be treated when also tagged with area=yes."
>
> Donc, cela veut dire qu'à part pour highway=pedestrian il n'y a pas de
> consensus sur l'utilisation d'area=yes pour les highway=*
>
>
>
> Le 22 mars 2012 17:19, Nicolas Moyroud  a écrit :
> > Le 22/03/2012 16:09, Florian LAINEZ a écrit :
> >
> > bonjour,
> > perso je ferrai passer la départementale à travers la area du marché.
> Pareil
> > pour l'autre route. Les areas ne sont pas faites pour être décrites en
> tant
> > que tertiary comme tu peux le voir sur le
> > wiki http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtertiary
> > ++
> >
> >
> > Merci pour cette précision. Pour moi les routes devaient se brancher sur
> > l'area sans le traverser. Quand j'ai commencé à mapper je traçais bien
> les
> > routes à travers les area mais ensuite j'ai été induit en erreur par
> cette
> > page du wiki : http://wiki.openstreetmap.org/wiki/Key:area
> > Dans cette page, highway=tertiary est même cité. J'avais mal lu et
> > l'illustration à droite m'a induit en erreur. Ça fait un bon bout de
> temps
> > que je fais cette erreur avec des highway=residential, il va falloir que
> je
> > revienne sur pas mal de mes area. Bon, y'a plus qu'à se retrousser les
> > manches ! ;-)
> > Comme quoi un mauvais rendu supposé des fois ça peut corriger des
> mauvaises
> > habitudes de mapping ! Merci mapnik et merci à ceux qui m'ont répondu :-)
> >
> > Nicolas
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
> >
>
>
>
> --
> Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Christian Quest]

Effectivement, cette page du wiki n'est pas bien claire et
contradictoire avec celle décrivant highway=tertiary

Le seul cas habituel ou un chemin fermé peut être taggué
highway=tertiary c'est le rond-point, mais il a aussi un
junction=roundabout et pas de area=yes

Un peu plus bas dans la même page est indiqué: "Note: There is
currently no clear agreement on how highway tag values other than
pedestrian should be treated when also tagged with area=yes."

Donc, cela veut dire qu'à part pour highway=pedestrian il n'y a pas de
consensus sur l'utilisation d'area=yes pour les highway=*



Le 22 mars 2012 17:19, Nicolas Moyroud  a écrit :
> Le 22/03/2012 16:09, Florian LAINEZ a écrit :
>
> bonjour,
> perso je ferrai passer la départementale à travers la area du marché. Pareil
> pour l'autre route. Les areas ne sont pas faites pour être décrites en tant
> que tertiary comme tu peux le voir sur le
> wiki http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtertiary
> ++
>
>
> Merci pour cette précision. Pour moi les routes devaient se brancher sur
> l'area sans le traverser. Quand j'ai commencé à mapper je traçais bien les
> routes à travers les area mais ensuite j'ai été induit en erreur par cette
> page du wiki : http://wiki.openstreetmap.org/wiki/Key:area
> Dans cette page, highway=tertiary est même cité. J'avais mal lu et
> l'illustration à droite m'a induit en erreur. Ça fait un bon bout de temps
> que je fais cette erreur avec des highway=residential, il va falloir que je
> revienne sur pas mal de mes area. Bon, y'a plus qu'à se retrousser les
> manches ! ;-)
> Comme quoi un mauvais rendu supposé des fois ça peut corriger des mauvaises
> habitudes de mapping ! Merci mapnik et merci à ceux qui m'ont répondu :-)
>
> Nicolas
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Nicolas Moyroud]

  
  
Le 22/03/2012 16:09, Florian LAINEZ a écrit :
bonjour,
  perso je ferrai passer la départementale à travers la area du
marché. Pareil pour l'autre route. Les areas ne sont pas faites
pour être décrites en tant que tertiary comme tu peux le voir
sur le wiki http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtertiary
  ++


Merci pour cette précision. Pour moi les routes devaient se brancher
sur l'area sans le traverser. Quand j'ai commencé à mapper je
traçais bien les routes à travers les area mais ensuite j'ai été
induit en erreur par cette page du wiki :
http://wiki.openstreetmap.org/wiki/Key:area
Dans cette page, highway=tertiary est même cité. J'avais mal lu et
l'illustration à droite m'a induit en erreur. Ça fait un bon bout de
temps que je fais cette erreur avec des highway=residential, il va
falloir que je revienne sur pas mal de mes area. Bon, y'a plus qu'à
se retrousser les manches !  ;-)
  
Comme quoi un mauvais rendu supposé des fois ça peut corriger des
mauvaises habitudes de mapping ! Merci mapnik et merci à ceux qui
m'ont répondu  :-) 

Nicolas

  


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

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Etienne Trimaille]

Tout à fait d'accord, il faut mettre le filière.
J'imagine que l'on pas le droit de conduire n'importe ou sur la place ? Il
y a quand même un marquage au sol pour les voies de circulation.

L'aspect surface vient avec une autre ligne fermé.

Et pourquoi pas une analyse osmose ?
Afin de repérer des cas comme çà :
http://www.openstreetmap.org/?lat=50.602201&lon=2.942501&zoom=18&layers=M



Le 22 mars 2012 16:19, Lapinos03  a écrit :

>  Le 22/03/12 15:00, Nicolas Moyroud a écrit :
>
> Bonjour,
>
> Je voudrais signaler un bug avec le rendu Mapnik concernant les area=yes
> sur des highway=tertiary. Voir par exemple ici :
> Plan du Barrie : http://osm.org/go/xVl98vzTQ--
> Plan Barthe et Place du Marché : http://osm.org/go/xVl_RBbvg--
> En changeant les higway en residential pas de souci d'affichage, mais je
> ne souhaite pas casser la continuité des tertiary et puis "on ne mappe pas
> pour le rendu" ;-)
> Il faut s'adresser à qui pour remonter le problème ?
>
> Nicolas
>
>
> Mais que fait la police ???
>
> D'un autre côté, je suis *contre* les area qui servent d'interconnexion.
> Les routes doivent se connecter directement entre elles pour expliciter les
> sens de circulation et la configuration du carrefour. Les area peuvent
> rester en fond si le contributeur souhaite avoir une représentation
> graphique de l'étendue du carrefour.
>
> /Lapi
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Lapinos03]

Le 22/03/12 15:00, Nicolas Moyroud a écrit :

Bonjour,

Je voudrais signaler un bug avec le rendu Mapnik concernant les 
area=yes sur des highway=tertiary. Voir par exemple ici :

Plan du Barrie : http://osm.org/go/xVl98vzTQ--
Plan Barthe et Place du Marché : http://osm.org/go/xVl_RBbvg--
En changeant les higway en residential pas de souci d'affichage, mais 
je ne souhaite pas casser la continuité des tertiary et puis "on ne 
mappe pas pour le rendu" ;-)

Il faut s'adresser à qui pour remonter le problème ?

Nicolas


Mais que fait la police ???

D'un autre côté, je suis *contre* les area qui servent d'interconnexion. 
Les routes doivent se connecter directement entre elles pour expliciter 
les sens de circulation et la configuration du carrefour. Les area 
peuvent rester en fond si le contributeur souhaite avoir une 
représentation graphique de l'étendue du carrefour.


/Lapi
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Florian LAINEZ]

bonjour,
perso je ferrai passer la départementale à travers la area du marché.
Pareil pour l'autre route. Les areas ne sont pas faites pour être décrites
en tant que tertiary comme tu peux le voir sur le wiki
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtertiary
++

Le 22 mars 2012 15:00, Nicolas Moyroud  a écrit :

> **
> Bonjour,
>
> Je voudrais signaler un bug avec le rendu Mapnik concernant les area=yes
> sur des highway=tertiary. Voir par exemple ici :
> Plan du Barrie : http://osm.org/go/xVl98vzTQ--
> Plan Barthe et Place du Marché : http://osm.org/go/xVl_RBbvg--
> En changeant les higway en residential pas de souci d'affichage, mais je
> ne souhaite pas casser la continuité des tertiary et puis "on ne mappe pas
> pour le rendu" ;-)
> Il faut s'adresser à qui pour remonter le problème ?
>
> Nicolas
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

*Florian Lainez*
http://twitter.com/overflorian
http://www.nouslesgeeks.fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Christian Quest]

A qui remonter le problème ? Au contributeur des area=yes sur les
highway=tertiary, non ?

C'est vraiment pas une bonne idée car un logiciel de calcul
d'itinéraire a bien du mal à faire quelque chose de ces données.

Que dis le wiki à propos de highway=tertiary ? à mettre uniquement sur
des ways ouverts, pas sur des surfaces...

http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtertiary


Le 22 mars 2012 15:00, Nicolas Moyroud  a écrit :
> Bonjour,
>
> Je voudrais signaler un bug avec le rendu Mapnik concernant les area=yes sur
> des highway=tertiary. Voir par exemple ici :
> Plan du Barrie : http://osm.org/go/xVl98vzTQ--
> Plan Barthe et Place du Marché : http://osm.org/go/xVl_RBbvg--
> En changeant les higway en residential pas de souci d'affichage, mais je ne
> souhaite pas casser la continuité des tertiary et puis "on ne mappe pas pour
> le rendu" ;-)
> Il faut s'adresser à qui pour remonter le problème ?
>
> Nicolas
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

[OSM-talk-fr] Bug de rendu Mapnik pour les area en highway=tertiary

[Nicolas Moyroud]

  
  
Bonjour,

Je voudrais signaler un bug avec le rendu Mapnik concernant les
area=yes sur des highway=tertiary. Voir par exemple ici :
Plan du Barrie : http://osm.org/go/xVl98vzTQ--
Plan Barthe et Place du Marché : http://osm.org/go/xVl_RBbvg--
En changeant les higway en residential pas de souci d'affichage,
mais je ne souhaite pas casser la continuité des tertiary et puis
"on ne mappe pas pour le rendu" 
;-) 
Il faut s'adresser à qui pour remonter le problème ?

Nicolas
  


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

Re: [OSM-talk-fr] Bug de rendu Mapnik : building sur zone piétonne ?

[Tenshu]

2010/5/26 Vincent Pottier 

> La réponse sera dans le micromapping, quand on fera les rues en
> polygones + way, comme les fleuves. 0 un certain niveau de zoom, le
> polygone prendra le pas sur le way.
>

N'empêche que l'on en est pas très loin.

-- 
Mon weblog - http://www.tenshu.fr/
Je soutiens le Logiciel Libre, j'adhère à l'APRIL !
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu Mapnik : building sur zone piétonne ?

[Vincent Pottier]

Le 26/05/2010 21:33, sly (sylvain letuffe) a écrit :
> On mercredi 26 mai 2010, simon wrote:
>
>> Perso, je refait la couche building, en filtrant pour n'afficher que
>> ceux ayant un layer supérieur à 0
>>  
> Pas idiot, j'y vois toutefois quelques cas où ça risque de faire
> cas cas (désolé...) :
>
> Si ton highway a un layer 3 et ton building un layer 2 ? (d'accord, ça doit
> pas courir lesponts  rues ;-) )
>
> Les cas de tunnels sous un building de layer>0, il est courant de vouloir
> afficher en pointiller le fait que la rue passe dessous. (cf arche de la
> défense sur ton svg)
>
> Et le cas dont parle LDP sur le forum, lorsque ton building est layer 1 (car
> une rue X passe dessous), qu'une rue Y passe à coté en étant logiquement
> layer 0, ton building va obscurcir la rue et rendre la lecture de son nom ou
> visibilité de sa forme plutôt hard (cf le triangle sur ton svg)
>
> Ta solution reste peut-être moins mauvaise que celle du map...@osm.org actuel,
> mais l'algorithme parfait va être chaud à trouver avec les possibilités des
> feuilles de styles...
>
>
La réponse sera dans le micromapping, quand on fera les rues en 
polygones + way, comme les fleuves. 0 un certain niveau de zoom, le 
polygone prendra le pas sur le way.

Vous avez dit : "Fromage et dessert" ?
-- 
FrViPofm

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

Re: [OSM-talk-fr] Bug de rendu Mapnik : building sur zone piétonne ?

[simon]

Le mercredi 26 mai 2010 à 21:33 +0200, sly (sylvain letuffe) a écrit : 
> On mercredi 26 mai 2010, simon wrote:
> > Perso, je refait la couche building, en filtrant pour n'afficher que
> > ceux ayant un layer supérieur à 0
> 
> Pas idiot, j'y vois toutefois quelques cas où ça risque de faire 
> cas cas (désolé...) :
> 
> Si ton highway a un layer 3 et ton building un layer 2 ? (d'accord, ça doit 
> pas courir les ponts rues ;-) )

il reste la solution ou on répète les couche pour chaque layer (je
n'imagine pas la taille de la feuille de style :) 
> 
> Les cas de tunnels sous un building de layer>0, il est courant de vouloir 
> afficher en pointiller le fait que la rue passe dessous. (cf arche de la 
> défense sur ton svg)

je viens de repasser les tunnels  au dessus 

http://www.monsieur-a.fr/test/test3.svg 

> 
> Et le cas dont parle LDP sur le forum, lorsque ton building est layer 1 (car 
> une rue X passe dessous), qu'une rue Y passe à coté en étant logiquement 
> layer 0, ton building va obscurcir la rue et rendre la lecture de son nom ou 
> visibilité de sa forme plutôt hard (cf le triangle sur ton svg)

je n'est pas mis ma couche de nom, mais je peut la mettre après les
buildings

> 
> Ta solution reste peut-être moins mauvaise que celle du map...@osm.org 
> actuel, 
> mais l'algorithme parfait va être chaud à trouver avec les possibilités des 
> feuilles de styles...
> 
a plusieurs on peut peut être réussir a proposer quelque chose de
meilleur a défaut d'être parfait ;)



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

Re: [OSM-talk-fr] Bug de rendu Mapnik : building sur zone piétonne ?

[sly (sylvain letuffe)]

On mercredi 26 mai 2010, simon wrote:
> Perso, je refait la couche building, en filtrant pour n'afficher que
> ceux ayant un layer supérieur à 0

Pas idiot, j'y vois toutefois quelques cas où ça risque de faire 
cas cas (désolé...) :

Si ton highway a un layer 3 et ton building un layer 2 ? (d'accord, ça doit 
pas courir les ponts rues ;-) )

Les cas de tunnels sous un building de layer>0, il est courant de vouloir 
afficher en pointiller le fait que la rue passe dessous. (cf arche de la 
défense sur ton svg)

Et le cas dont parle LDP sur le forum, lorsque ton building est layer 1 (car 
une rue X passe dessous), qu'une rue Y passe à coté en étant logiquement 
layer 0, ton building va obscurcir la rue et rendre la lecture de son nom ou 
visibilité de sa forme plutôt hard (cf le triangle sur ton svg)

Ta solution reste peut-être moins mauvaise que celle du map...@osm.org actuel, 
mais l'algorithme parfait va être chaud à trouver avec les possibilités des 
feuilles de styles...

-- 
sly
Sylvain Letuffe sylv...@letuffe.org
qui suis-je : http://slyserv.dyndns.org



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

Re: [OSM-talk-fr] Bug de rendu Mapnik : building sur zone piétonne ?

[simon]

Le mercredi 26 mai 2010 à 19:48 +0200, sly (sylvain letuffe) a écrit : 
> On mercredi 26 mai 2010, Pieren wrote:
> > 2010/5/26 OSM Léon 
> > 
> > > La Grande Arche de La Défense à proximité de Paris est bien cartographiée
> > > mais elle n'apparaît pas sur le rendu Mapnik :
> > > http://osm.org/go/0BPCaxIn3--
> > >
> > >
> > Signalé ici:
> > http://trac.openstreetmap.org/ticket/2153
> 
> Mon style de rendu datant de l'avant guerre s'en sort un peux mieux, donc ça 
> ressemble un peu à une régression, mais je suppose que le mien doit disposer 
> de tout un tas de bugs corrigés depuis
> http://beta.letuffe.org/?lat=48.85831&lon=2.29375&zoom=18&layers=0B000
> 
> 

Perso, je refait la couche building, en filtrant pour n'afficher que
ceux ayant un layer supérieur à 0, après avoir fait le rendu de toute
mes highway  

http://www.monsieur-a.fr/test/test2.svg 


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

Re: [OSM-talk-fr] Bug de rendu Mapnik : building su r zone piétonne ?

[sly (sylvain letuffe)]

On mercredi 26 mai 2010, Pieren wrote:
> 2010/5/26 OSM Léon 
> 
> > La Grande Arche de La Défense à proximité de Paris est bien cartographiée
> > mais elle n'apparaît pas sur le rendu Mapnik :
> > http://osm.org/go/0BPCaxIn3--
> >
> >
> Signalé ici:
> http://trac.openstreetmap.org/ticket/2153

Mon style de rendu datant de l'avant guerre s'en sort un peux mieux, donc ça 
ressemble un peu à une régression, mais je suppose que le mien doit disposer 
de tout un tas de bugs corrigés depuis
http://beta.letuffe.org/?lat=48.85831&lon=2.29375&zoom=18&layers=0B000



-- 
sly
Sylvain Letuffe sylv...@letuffe.org
qui suis-je : http://slyserv.dyndns.org



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

Re: [OSM-talk-fr] Bug de rendu Mapnik : building sur zone piétonne ?

[Pieren]

2010/5/26 OSM Léon 

> La Grande Arche de La Défense à proximité de Paris est bien cartographiée
> mais elle n'apparaît pas sur le rendu Mapnik :
> http://osm.org/go/0BPCaxIn3--
>
>
Signalé ici:
http://trac.openstreetmap.org/ticket/2153

Une solution de bricolage est de tagguer l'area en multipolygone mais c'est
tagguer pour le rendu (même s'il m'est arrivé de le faire) encore que, il y
a des arguments pour (voir en bas). Il y a le même problème sous la tour
Eiffel mais le bricolage avec la relation ne peut même pas fonctionner dans
ce cas parce que la tour déborde du polygone pedestrian !

Pieren

PS: on en parle aussi sur le forum:
http://forum.openstreetmap.org/viewtopic.php?id=7590
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Bug de rendu Mapnik : building sur zone piétonne ?

[OSM Léon]

La Grande Arche de La Défense à proximité de Paris est bien cartographiée
mais elle n'apparaît pas sur le rendu Mapnik : http://osm.org/go/0BPCaxIn3--

Pourtant j'ai vérifié : les layers sont cohérents, pas de soucis de ce côté.
Une idée d'où ça pourrait venir ? Les buildings construits sur des area=yes
+ highway=pedestrian ne sont pas rendus par Mapnik ? Si oui c'est dommage,
ça fait comme un gros trou :D

NB : pas de soucis avec osmarender par exemple
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Axel R.]

> Je parle pas des ressources des clients mais du coté serveur, difficile
> de détecter la compléxité d'une tuile.
>   
et la taille du bloc OSM récuperé n'implique par la compléxité de la tuile ?

>
> Tout est dans le wiki et le svn, il faut juste chercher un peu.
>   
Je demandai justement parce que je n'avais pas trouvé ça.
J'ai juste trouvé le schéma "général" :
http://wiki.openstreetmap.org/index.php/Component_overview

Merci,

Axel


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Steven Le Roux]

2008/7/30 Rodolphe Quiedeville <[EMAIL PROTECTED]>

> Axel R. a écrit :
> >> Pour le moment [EMAIL PROTECTED] est totalement ouvert à qui veut 
> >> participer/casser
> >> ;-) Ce genre de règle ne pourra être mise en oeuvre que beaucoup plus
> >> tard à mon avis car c'est enormément consommateur de ressource.
> >>
> > Je comprends pas pourquoi. Je pense au contraire que ça permettrait
> > d'économiser des ressources.
>
> Je parle pas des ressources des clients mais du coté serveur, difficile
> de détecter la compléxité d'une tuile.


Je pense que ça reste assez simpl eà implémenter dans le sens où on peut
déjà taguer des tuiles en land/sea/... du coup on pourrait ajouter un tag
complex pour réserver ces rendus aux plus grosses machines.
Il reste à mettre un ordonanceur en place pour diriger des rendus à des
machines plutôt que d'autres.


>
>
> > Actuellement, on fait le rendu pour les tuiles de niveau 12 et supérieur.
> > Si on n'autorisait les  rendus qu'à partir du niveau 13, certaines
> > personnes calculerait peut être les 4 tuiles de niveau 13 qui sont dans
> > celle de niveau 12, mais peut être qu'ils n'en auraient besoin que d'une
> > ou deux.
> >
> > Rien à voir ou presque, je me demandais si y'avait quelque part des
> > explications sur comment fonctionne [EMAIL PROTECTED] et les logiciels 
> > qu'il utilise
> > en dessous.
> > Qu'est ce qui transforme quoi en quoi ?
>
> Tout est dans le wiki et le svn, il faut juste chercher un peu.
>
> A++
>
> --
> Rodolphe Quiédeville - Artisan Logiciel Libre
> http://rodolphe.quiedeville.org/
> Travaillons Libre - http://fr.lolix.org/
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>
>


-- 
Steven Le Roux
Jabber-ID : [EMAIL PROTECTED]
0x39494CCB <[EMAIL PROTECTED]>
2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Philippe Piquer]

D'un autre coté, vu le nombre de participants plus importants que
initialement prévu , ils ne répondent plus aux demandes pour participer ...

2008/7/30 Rodolphe Quiedeville <[EMAIL PROTECTED]>

> Axel R. a écrit :
> >> Pour le moment [EMAIL PROTECTED] est totalement ouvert à qui veut 
> >> participer/casser
> >> ;-) Ce genre de règle ne pourra être mise en oeuvre que beaucoup plus
> >> tard à mon avis car c'est enormément consommateur de ressource.
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Rodolphe Quiedeville]

Axel R. a écrit :
>> Pour le moment [EMAIL PROTECTED] est totalement ouvert à qui veut 
>> participer/casser
>> ;-) Ce genre de règle ne pourra être mise en oeuvre que beaucoup plus
>> tard à mon avis car c'est enormément consommateur de ressource.
>>   
> Je comprends pas pourquoi. Je pense au contraire que ça permettrait 
> d'économiser des ressources.

Je parle pas des ressources des clients mais du coté serveur, difficile
de détecter la compléxité d'une tuile.

> Actuellement, on fait le rendu pour les tuiles de niveau 12 et supérieur.
> Si on n'autorisait les  rendus qu'à partir du niveau 13, certaines 
> personnes calculerait peut être les 4 tuiles de niveau 13 qui sont dans 
> celle de niveau 12, mais peut être qu'ils n'en auraient besoin que d'une 
> ou deux.
> 
> Rien à voir ou presque, je me demandais si y'avait quelque part des 
> explications sur comment fonctionne [EMAIL PROTECTED] et les logiciels qu'il 
> utilise 
> en dessous.
> Qu'est ce qui transforme quoi en quoi ?

Tout est dans le wiki et le svn, il faut juste chercher un peu.

A++

-- 
Rodolphe Quiédeville - Artisan Logiciel Libre
http://rodolphe.quiedeville.org/
Travaillons Libre - http://fr.lolix.org/



signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Axel R.]

> Pour le moment [EMAIL PROTECTED] est totalement ouvert à qui veut 
> participer/casser
> ;-) Ce genre de règle ne pourra être mise en oeuvre que beaucoup plus
> tard à mon avis car c'est enormément consommateur de ressource.
>   
Je comprends pas pourquoi. Je pense au contraire que ça permettrait 
d'économiser des ressources.
Actuellement, on fait le rendu pour les tuiles de niveau 12 et supérieur.
Si on n'autorisait les  rendus qu'à partir du niveau 13, certaines 
personnes calculerait peut être les 4 tuiles de niveau 13 qui sont dans 
celle de niveau 12, mais peut être qu'ils n'en auraient besoin que d'une 
ou deux.

Rien à voir ou presque, je me demandais si y'avait quelque part des 
explications sur comment fonctionne [EMAIL PROTECTED] et les logiciels qu'il 
utilise 
en dessous.
Qu'est ce qui transforme quoi en quoi ?

Merci,

Axel


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Rodolphe Quiedeville]

Axel R. a écrit :
>> Oui il y a une activité, les deux tuiles manquantes au niveau 12 ont été
>> correctement générées, mais comme dit précédemment le rendu se compte en
>> heures (machine bi-quadcore).
>>   
> Merci beaucoup Rodolphe pour ce rendu.
> N'est il pas un peu dangeureux de laisser n'importe qui faire une 
> demande de rendu pour une tuile qui ne peut être calculé que dans 
> certaines circonstances ?
> Je ne sais pas comment fonctionne [EMAIL PROTECTED], mais je pense qu'il 
> serait plus 
> judicieux d'interdire les rendus de zoom 12 quand les données sont trop 
> importante et n'autoriser que les rendus de zoom supérieur.

Pour le moment [EMAIL PROTECTED] est totalement ouvert à qui veut 
participer/casser
;-) Ce genre de règle ne pourra être mise en oeuvre que beaucoup plus
tard à mon avis car c'est enormément consommateur de ressource.

A++


-- 
Rodolphe Quiédeville - Artisan Logiciel Libre
http://rodolphe.quiedeville.org/
Travaillons Libre - http://fr.lolix.org/



signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Axel R.]

> Oui il y a une activité, les deux tuiles manquantes au niveau 12 ont été
> correctement générées, mais comme dit précédemment le rendu se compte en
> heures (machine bi-quadcore).
>   
Merci beaucoup Rodolphe pour ce rendu.
N'est il pas un peu dangeureux de laisser n'importe qui faire une 
demande de rendu pour une tuile qui ne peut être calculé que dans 
certaines circonstances ?
Je ne sais pas comment fonctionne [EMAIL PROTECTED], mais je pense qu'il serait 
plus 
judicieux d'interdire les rendus de zoom 12 quand les données sont trop 
importante et n'autoriser que les rendus de zoom supérieur.

Axel


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Steven Le Roux]

2008/7/30 Rodolphe Quiedeville <[EMAIL PROTECTED]>

> Steven Le Roux a écrit :
> >
> >
> > 2008/7/30 Rodolphe Quiedeville <[EMAIL PROTECTED]
> > >
> >
> > Axel Rousseau a écrit :
> > >> Bob je vais sortir l'artillerie lourde alors.
> > >> Je vais lancer un rendu avec un machine 8go
> > >>
> > > Pfff, mais quel frimeur ! :-)
> > > Plus sérieusement, y'a un problème si certains tiles ne peuvent
> être
> > > calculé que par certaines machines.
> > > D'où ma question de ce matin d'une solution pour effectuer des
> rendus
> > > qu'à des zoom plus élevés...et laisser les zooms d'un niveau 14
> qu'aux
> > > grosses machines.
> >
> > Cela n'a pas suffit. J'ai changer le garbage collector comme indiqué
> sur
> > la ML, le rendu a l'air de se faire correctement, mais c'est plutôt
> > long, il tourne depuis 3H déjà, alors le résultat sera pour demain.
> >
> >
> > tu as bien une activité ?
> >
> > car dans mon cas j'ai un freeze en etat "rendering" mais aucune activité
> > CPU...
>
> Oui il y a une activité, les deux tuiles manquantes au niveau 12 ont été
> correctement générées, mais comme dit précédemment le rendu se compte en
> heures (machine bi-quadcore).
>
>
> http://informationfreeway.org/?lat=48.83833664054544&lon=2.352470288328392&zoom=12&layers=B000F000F
>
> A++
>

ah bien !!

mes bi quad core n'en n'était pas venu à bout...

>
>
> --
> Rodolphe Quiédeville - Artisan Logiciel Libre
> http://rodolphe.quiedeville.org/
> Travaillons Libre - http://fr.lolix.org/
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>
>


-- 
Steven Le Roux
Jabber-ID : [EMAIL PROTECTED]
0x39494CCB <[EMAIL PROTECTED]>
2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Rodolphe Quiedeville]

Axel Rousseau a écrit :
>> Bob je vais sortir l'artillerie lourde alors.
>> Je vais lancer un rendu avec un machine 8go
>>   
> Pfff, mais quel frimeur ! :-)

Ce sont les machines du boulot pas la mienne perso ;-) Autant utiliser
les ressources dispo non ?

A++

-- 
Rodolphe Quiédeville - Artisan Logiciel Libre
http://rodolphe.quiedeville.org/
Travaillons Libre - http://fr.lolix.org/



signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Rodolphe Quiedeville]

Steven Le Roux a écrit :
> 
> 
> 2008/7/30 Rodolphe Quiedeville <[EMAIL PROTECTED]
> >
> 
> Axel Rousseau a écrit :
> >> Bob je vais sortir l'artillerie lourde alors.
> >> Je vais lancer un rendu avec un machine 8go
> >>
> > Pfff, mais quel frimeur ! :-)
> > Plus sérieusement, y'a un problème si certains tiles ne peuvent être
> > calculé que par certaines machines.
> > D'où ma question de ce matin d'une solution pour effectuer des rendus
> > qu'à des zoom plus élevés...et laisser les zooms d'un niveau 14 qu'aux
> > grosses machines.
> 
> Cela n'a pas suffit. J'ai changer le garbage collector comme indiqué sur
> la ML, le rendu a l'air de se faire correctement, mais c'est plutôt
> long, il tourne depuis 3H déjà, alors le résultat sera pour demain.
> 
> 
> tu as bien une activité ?
> 
> car dans mon cas j'ai un freeze en etat "rendering" mais aucune activité
> CPU...

Oui il y a une activité, les deux tuiles manquantes au niveau 12 ont été
correctement générées, mais comme dit précédemment le rendu se compte en
heures (machine bi-quadcore).

http://informationfreeway.org/?lat=48.83833664054544&lon=2.352470288328392&zoom=12&layers=B000F000F

A++

-- 
Rodolphe Quiédeville - Artisan Logiciel Libre
http://rodolphe.quiedeville.org/
Travaillons Libre - http://fr.lolix.org/



signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Steven Le Roux]

2008/7/30 Rodolphe Quiedeville <[EMAIL PROTECTED]>

> Axel Rousseau a écrit :
> >> Bob je vais sortir l'artillerie lourde alors.
> >> Je vais lancer un rendu avec un machine 8go
> >>
> > Pfff, mais quel frimeur ! :-)
> > Plus sérieusement, y'a un problème si certains tiles ne peuvent être
> > calculé que par certaines machines.
> > D'où ma question de ce matin d'une solution pour effectuer des rendus
> > qu'à des zoom plus élevés...et laisser les zooms d'un niveau 14 qu'aux
> > grosses machines.
>
> Cela n'a pas suffit. J'ai changer le garbage collector comme indiqué sur
> la ML, le rendu a l'air de se faire correctement, mais c'est plutôt
> long, il tourne depuis 3H déjà, alors le résultat sera pour demain.
>

tu as bien une activité ?

car dans mon cas j'ai un freeze en etat "rendering" mais aucune activité
CPU...



>
> A++
>
>
> --
> Rodolphe Quiédeville - Artisan Logiciel Libre
> http://rodolphe.quiedeville.org/
> Travaillons Libre - http://fr.lolix.org/
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>
>


-- 
Steven Le Roux
Jabber-ID : [EMAIL PROTECTED]
0x39494CCB <[EMAIL PROTECTED]>
2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Rodolphe Quiedeville]

Axel Rousseau a écrit :
>> Bob je vais sortir l'artillerie lourde alors.
>> Je vais lancer un rendu avec un machine 8go
>>   
> Pfff, mais quel frimeur ! :-)
> Plus sérieusement, y'a un problème si certains tiles ne peuvent être 
> calculé que par certaines machines.
> D'où ma question de ce matin d'une solution pour effectuer des rendus 
> qu'à des zoom plus élevés...et laisser les zooms d'un niveau 14 qu'aux 
> grosses machines.

Cela n'a pas suffit. J'ai changer le garbage collector comme indiqué sur
la ML, le rendu a l'air de se faire correctement, mais c'est plutôt
long, il tourne depuis 3H déjà, alors le résultat sera pour demain.

A++


-- 
Rodolphe Quiédeville - Artisan Logiciel Libre
http://rodolphe.quiedeville.org/
Travaillons Libre - http://fr.lolix.org/



signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Axel Rousseau]

> Bob je vais sortir l'artillerie lourde alors.
> Je vais lancer un rendu avec un machine 8go
>   
Pfff, mais quel frimeur ! :-)
Plus sérieusement, y'a un problème si certains tiles ne peuvent être 
calculé que par certaines machines.
D'où ma question de ce matin d'une solution pour effectuer des rendus 
qu'à des zoom plus élevés...et laisser les zooms d'un niveau 14 qu'aux 
grosses machines.

De toutes façons, c'est comme le zoom 8, c'est pas grave si c'est pas 
fait tout de suite, ce qui est important c'est de pouvoir voir les 
détails quand on se rapproche :)

Axel

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Rodolphe Quiedeville]

Steven Le Roux a écrit :
> 
> 
> 2008/7/29 Pieren <[EMAIL PROTECTED] >
> 
> il "existerait" une solution dans la ML de [EMAIL PROTECTED] :
> 
> http://lists.openstreetmap.org/pipermail/tilesathome/2008-February/001835.html
> 
> Pour résumer, il faut recompiler inkscape avec un autre garbage
> collector qui supporte de plus grosses quantités de données mais je
> n'ai pas compris les détails.
> 
> Par contre, il semblerait que le rendu d'autres grandes villes pose
> ce problème depuis quelque temps déjà
> 
> (http://lists.openstreetmap.org/pipermail/tilesathome/2008-February/001834.html,
> 4 Go de RAM + 4 Go de swap).
> 
> 
> j'ai lu que berlin ou qq villes allemandes ne pouvaient pas être rendues
> sans 8go de ram...
> 
> j'ai pas ça en stock pour le moment ;)

Bob je vais sortir l'artillerie lourde alors.
Je vais lancer un rendu avec un machine 8go

A++

-- 
Rodolphe Quiédeville - Artisan Logiciel Libre
http://rodolphe.quiedeville.org/
Travaillons Libre - http://fr.lolix.org/



signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Steven Le Roux]

2008/7/29 Pieren <[EMAIL PROTECTED]>

> il "existerait" une solution dans la ML de [EMAIL PROTECTED] :
>
> http://lists.openstreetmap.org/pipermail/tilesathome/2008-February/001835.html
>
> Pour résumer, il faut recompiler inkscape avec un autre garbage collector
> qui supporte de plus grosses quantités de données mais je n'ai pas compris
> les détails.
>
> Par contre, il semblerait que le rendu d'autres grandes villes pose ce
> problème depuis quelque temps déjà (
> http://lists.openstreetmap.org/pipermail/tilesathome/2008-February/001834.html,
> 4 Go de RAM + 4 Go de swap).
>

j'ai lu que berlin ou qq villes allemandes ne pouvaient pas être rendues
sans 8go de ram...

j'ai pas ça en stock pour le moment ;)


>
>
> On Tue, Jul 29, 2008 at 5:37 PM, Axel R. <[EMAIL PROTECTED]>wrote:
>
>> Je ne pense pas que ça résolve le problème, Rodolphe a essayé avec 4 Go
>> de RAM et ça plante avant d'avoir tout rempli la mémoire.
>> Je pense qu'il y a un truc qu'Inskape n'aime pas trop et qui le fait
>> planter...
>> Mais de là à savoir quoi...
>>
>> Axel
>>
>> > qelle est la taille du fichier svg ? et en augmentant la taille du swap
>> ?
>> > Pieren
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>
>


-- 
Steven Le Roux
Jabber-ID : [EMAIL PROTECTED]
0x39494CCB <[EMAIL PROTECTED]>
2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Steven Le Roux]

2008/7/29 Steven Le Roux <[EMAIL PROTECTED]>

>
>
> 2008/7/29 Pieren <[EMAIL PROTECTED]>
>
>> qelle est la taille du fichier svg ? et en augmentant la taille du swap ?
>> Pieren
>>
>
> ça sert à rien car ça ne swap pas...
>
>
> idem que rodolphe, j'ai mes bi-quadcore xeon qui plante, et mes bi-opteron
> ne font pas mieux (pourtant 3à 4go de ram chaque)
>
> mais actuellement j'arrive à un freeze de inkscape et plus un "out of
> memory" donc là j'ai changé inkscape pour batik et en rendu est en cours...
> résultats dans qq minutes...
>
>
ça n'a pas trainé... et c'est un echec :) retour sur inkscape...

>
> --
> Steven Le Roux
> Jabber-ID : [EMAIL PROTECTED]
> 0x39494CCB <[EMAIL PROTECTED]>
> 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
>



-- 
Steven Le Roux
Jabber-ID : [EMAIL PROTECTED]
0x39494CCB <[EMAIL PROTECTED]>
2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Pieren]

il "existerait" une solution dans la ML de [EMAIL PROTECTED] :
http://lists.openstreetmap.org/pipermail/tilesathome/2008-February/001835.html

Pour résumer, il faut recompiler inkscape avec un autre garbage collector
qui supporte de plus grosses quantités de données mais je n'ai pas compris
les détails.

Par contre, il semblerait que le rendu d'autres grandes villes pose ce
problème depuis quelque temps déjà (
http://lists.openstreetmap.org/pipermail/tilesathome/2008-February/001834.html,
4 Go de RAM + 4 Go de swap).

On Tue, Jul 29, 2008 at 5:37 PM, Axel R. <[EMAIL PROTECTED]> wrote:

> Je ne pense pas que ça résolve le problème, Rodolphe a essayé avec 4 Go
> de RAM et ça plante avant d'avoir tout rempli la mémoire.
> Je pense qu'il y a un truc qu'Inskape n'aime pas trop et qui le fait
> planter...
> Mais de là à savoir quoi...
>
> Axel
>
> > qelle est la taille du fichier svg ? et en augmentant la taille du swap ?
> > Pieren
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Steven Le Roux]

2008/7/29 Pieren <[EMAIL PROTECTED]>

> qelle est la taille du fichier svg ? et en augmentant la taille du swap ?
> Pieren
>

ça sert à rien car ça ne swap pas...


idem que rodolphe, j'ai mes bi-quadcore xeon qui plante, et mes bi-opteron
ne font pas mieux (pourtant 3à 4go de ram chaque)

mais actuellement j'arrive à un freeze de inkscape et plus un "out of
memory" donc là j'ai changé inkscape pour batik et en rendu est en cours...
résultats dans qq minutes...


-- 
Steven Le Roux
Jabber-ID : [EMAIL PROTECTED]
0x39494CCB <[EMAIL PROTECTED]>
2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Megaten]

J'ai fais un essai il y a quelques semaine, voici ce que cela donne en 
Mapnik.

http://www.openstreetmap.org/?lat=48.389&lon=2.4939&zoom=14&layers=0BFT

J'ai trouvé les relations un peu 'lourdes'

[EMAIL PROTECTED] a écrit :
> J'ai testé dans ma rue, la numérotation fonctionne bien sous Osmarender.
> http://informationfreeway.org/?lat=48.78418755387773&lon=2.131370482701624&zoom=17&layers=B000F000F
>
> wagner51
>
> - Mail Original -
> De: "JonathanMM" <[EMAIL PROTECTED]>
> À: "Discussions sur OSM en francais" 
> Envoyé: Mardi 29 Juillet 2008 12:40:57 GMT +01:00 Amsterdam / Berlin / Berne 
> / Rome / Stockholm / Vienne
> Objet: Re: [OSM-talk-fr] Bug de rendu
>
> Ça fait longtemps que c'est en discutions, on en a parlé lors de la 
> dernière réunion IRC francophone.
> C'est pas très d'être réglé cette histoire
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>
>   

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Axel R.]

Je ne pense pas que ça résolve le problème, Rodolphe a essayé avec 4 Go 
de RAM et ça plante avant d'avoir tout rempli la mémoire.
Je pense qu'il y a un truc qu'Inskape n'aime pas trop et qui le fait 
planter...
Mais de là à savoir quoi...

Axel

> qelle est la taille du fichier svg ? et en augmentant la taille du swap ?
> Pieren



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Pieren]

qelle est la taille du fichier svg ? et en augmentant la taille du swap ?
Pieren

On Tue, Jul 29, 2008 at 4:52 PM, Axel R. <[EMAIL PROTECTED]> wrote:

>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Charlie Echo]

J'ai relancé la question de la numérotation sur la liste anglaise, en proposant 
un schéma qui correspond à ce que j'ai toujours vu faire sur les plans papier.

J'ai ouvert la boîte de Pandore, ça débat encore, et ça ne va pas être réglé 
cette fois-ci...


- Mail Original -
De: [EMAIL PROTECTED]
À: "Discussions sur OSM en français" 
Envoyé: Mardi 29 Juillet 2008 15:01:34 GMT +01:00 Amsterdam / Berlin / Berne / 
Rome / Stockholm / Vienne
Objet: Re: [OSM-talk-fr] Bug de rendu

J'ai testé dans ma rue, la numérotation fonctionne bien sous Osmarender.
http://informationfreeway.org/?lat=48.78418755387773&lon=2.131370482701624&zoom=17&layers=B000F000F

wagner51

- Mail Original -
De: "JonathanMM" <[EMAIL PROTECTED]>
À: "Discussions sur OSM en francais" 
Envoyé: Mardi 29 Juillet 2008 12:40:57 GMT +01:00 Amsterdam / Berlin / Berne / 
Rome / Stockholm / Vienne
Objet: Re: [OSM-talk-fr] Bug de rendu

Ça fait longtemps que c'est en discutions, on en a parlé lors de la 
dernière réunion IRC francophone.
C'est pas très d'être réglé cette histoire

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Axel R.]

> Salut,
>
> Je l'ai lancé sur une machine avec 4Go de RAM et pareil cela plante et
> cela sans que toute la RAM ne soit consommée, le bug n'est donc pas du à
> un manque de RAM de la machine.
>
> A++
>   
Youpi ! je suis pas obligé de racheter de la RAM :-)
Bon, et maintenant, on fait quoi ?

Axel



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Rodolphe Quiedeville]

Axel R. a écrit :
> Bonjour,
> En essayant de faire un rendu du sud de Paris, mon [EMAIL PROTECTED] se 
> plante 
> avec le message suivant :
> 
> Updated to revision 9317.
> [#1   0% jobinit] Doing tileset 2074,1409 (zoom 12) (area around 
> 48.835789,2.329102)
> [#1   0% Preproc] Downloading: Map data for captionless,default,maplint 
> to /tmp/[#1   3% default] Rendering... 

Salut,

Je l'ai lancé sur une machine avec 4Go de RAM et pareil cela plante et
cela sans que toute la RAM ne soit consommée, le bug n'est donc pas du à
un manque de RAM de la machine.

A++


-- 
Rodolphe Quiédeville - Artisan Logiciel Libre
http://rodolphe.quiedeville.org/
Travaillons Libre - http://fr.lolix.org/



signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[jblum]

J'ai testé dans ma rue, la numérotation fonctionne bien sous Osmarender.
http://informationfreeway.org/?lat=48.78418755387773&lon=2.131370482701624&zoom=17&layers=B000F000F

wagner51

- Mail Original -
De: "JonathanMM" <[EMAIL PROTECTED]>
À: "Discussions sur OSM en francais" 
Envoyé: Mardi 29 Juillet 2008 12:40:57 GMT +01:00 Amsterdam / Berlin / Berne / 
Rome / Stockholm / Vienne
Objet: Re: [OSM-talk-fr] Bug de rendu

Ça fait longtemps que c'est en discutions, on en a parlé lors de la 
dernière réunion IRC francophone.
C'est pas très d'être réglé cette histoire

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[JonathanMM]

Ça fait longtemps que c'est en discutions, on en a parlé lors de la 
dernière réunion IRC francophone.
C'est pas très d'être réglé cette histoire

JonathanMM

Axel R. a écrit :
> Je sais pas si vous avez vu la page principale du wiki anglais, mais
> l'image de la semaine parle du projet de numérotation des maisons...

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Steven Le Roux]

Bon un pb de raid non reconnu j'arrive pas à installer ma debian... flutte!

2008/7/29 Axel R. <[EMAIL PROTECTED]>

>
> > Le rendu en z12 ne fait pas que 12, il fait de 12 à 17.
> >
> >
> C'est bien ça le problème :-)
> Quand on fait ça sur Paris, ça prends énormément de temps et de
> ressource...
>
> Et j'ai pas encore mis les numéros des maisons ;-)
>
> Je sais pas si vous avez vu la page principale du wiki anglais, mais
> l'image de la semaine parle du projet de numérotation des maisons...
>
> Axel
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>



-- 
Steven Le Roux
Jabber-ID : [EMAIL PROTECTED]
0x39494CCB <[EMAIL PROTECTED]>
2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Axel R.]

> Le rendu en z12 ne fait pas que 12, il fait de 12 à 17.
>
>   
C'est bien ça le problème :-)
Quand on fait ça sur Paris, ça prends énormément de temps et de ressource...

Et j'ai pas encore mis les numéros des maisons ;-)

Je sais pas si vous avez vu la page principale du wiki anglais, mais 
l'image de la semaine parle du projet de numérotation des maisons...

Axel



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Gwenn]

> D'autre part, y'a t'il une possibilité de faire le rendu pour des
> zooms plus élevé que 12 ?  Parce que quand je change une boîte aux
> lettres ou ce genre de conneries, je ferais bien un rendu à un zoom
> de 16 ou 17.

Le rendu en z12 ne fait pas que 12, il fait de 12 à 17.

-- 
Gwenn

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Axel R.]

>
> ooch ! mes 3go de ram n'ont pas suffit :)
>
> dernier recours.. je fini d'installer un monstre et je relance ;)
Y'aurait pas un bug qui fait qu'il bouclerait sur un problème jusqu'à 
occuper toute la RAM ?
Faudrait peut etre demander à la mailing list US, quelqu'un est déjà 
dessus ?

D'autre part, y'a t'il une possibilité de faire le rendu pour des zooms 
plus élevé que 12 ?
Parce que quand je change une boîte aux lettres ou ce genre de 
conneries, je ferais bien un rendu à un zoom de 16 ou 17.

Merci,

Axel


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Steven Le Roux]

2008/7/29 Steven Le Roux <[EMAIL PROTECTED]>

>
>
> 2008/7/29 Axel Rousseau <[EMAIL PROTECTED]>
>
>> Maintenant qu'il refonctionne, j'ai toujours un problème pour cette tiles.
>>
>> Quelqu'un pourrait essayer de calculer le rendu pour la tiles suivante :
>> 12/2074/1409
>> Ainsi que sa petite soeur : 12/2075/1409
>>
>> Merci beaucoup,
>>
>
> Oui je le lance.
>

ooch ! mes 3go de ram n'ont pas suffit :)

dernier recours.. je fini d'installer un monstre et je relance ;)



>
>
>
> --
> Steven Le Roux
> Jabber-ID : [EMAIL PROTECTED]
> 0x39494CCB <[EMAIL PROTECTED]>
> 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
>



-- 
Steven Le Roux
Jabber-ID : [EMAIL PROTECTED]
0x39494CCB <[EMAIL PROTECTED]>
2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Steven Le Roux]

2008/7/29 Axel Rousseau <[EMAIL PROTECTED]>

> Maintenant qu'il refonctionne, j'ai toujours un problème pour cette tiles.
>
> Quelqu'un pourrait essayer de calculer le rendu pour la tiles suivante :
> 12/2074/1409
> Ainsi que sa petite soeur : 12/2075/1409
>
> Merci beaucoup,
>

Oui je le lance.



-- 
Steven Le Roux
Jabber-ID : [EMAIL PROTECTED]
0x39494CCB <[EMAIL PROTECTED]>
2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Axel Rousseau]

Maintenant qu'il refonctionne, j'ai toujours un problème pour cette tiles.

Quelqu'un pourrait essayer de calculer le rendu pour la tiles suivante : 
12/2074/1409
Ainsi que sa petite soeur : 12/2075/1409

Merci beaucoup,

Axel
> le serveur [EMAIL PROTECTED] est un peu sur le cul pour le moment ... cela 
> pourrait 
> il etre lié ?
> 
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>   


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Philippe Piquer]

le serveur [EMAIL PROTECTED] est un peu sur le cul pour le moment ... cela 
pourrait il
etre lié ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Axel R.]

Bonne idée, mais je dois pas être le seul.
J'ai un gros carré blanc sur la carte...
Au niveau de la ville de Montrouge (ville qui touche Paris au sud)

Axel

> Hello,
>
> (inkscape:21965): WARNING **: GC Warning: Out of Memory!
>
> Que faire ? Acheter de la RAM je crois...
>
> On Mon, Jul 28, 2008 at 12:34 PM, Axel R. <[EMAIL PROTECTED] 
> > wrote:
>
> Bonjour,
> En essayant de faire un rendu du sud de Paris, mon [EMAIL PROTECTED] se
> plante
> avec le message suivant :
>
> Updated to revision 9317.
> [#1   0% jobinit] Doing tileset 2074,1409 (zoom 12) (area around
> 48.835789,2.329102)
> [#1   0% Preproc] Downloading: Map data for
> captionless,default,maplint
> to /tmp/[#1   3% default] Rendering...
> ERROR  The following
> command
> produced an error message:
>  LC_ALL=C nice -n10 "inkscape" -z -w 1024 -h 256
> --export-area=0.00:658.661491:878.91:878.215322
> --export-png="/tmp/6125/6125_part-AKOVC2.png"
> "/tmp/output-6125-z14.svg"
>  > /tmp/6125-x05TpS.stdout
>  Debug output follows:
>  |
>  | ** (inkscape:21965): WARNING **: GC Warning: Repeated allocation of
> very large block (appr. size 16384):
>  | May lead to memory leak and poor performance.
>  |
>  |
>  | ** (inkscape:21965): WARNING **: GC Warning: Out of Memory!
> Returning NIL!
>  |
>  | terminate called after throwing an instance of 'std::bad_alloc'
>  |   what():  std::bad_alloc
>  |
>  | Emergency save activated!
>  | Emergency save completed. Inkscape will close now.
>  | If you can reproduce this crash, please file a bug at
> www.inkscape.org 
>  | with a detailed description of the steps leading to the crash,
> so we
> can fix it.
>  | ** Message: Error: Inkscape encountered an internal error and will
> close now.
>  |
>  | Aborted
>
> Additional info about the Error(s):
>
>
> [#1   3% default] LC_ALL=C nice -n10 "inkscape" -z -w 1024 -h 256
> --export-area=0.00:658.661491:878.91:878.215322
> --export-png="/tmp/6125/6125_part-AKOVC2.png"
> "/tmp/output-6125-z14.svg"
>  > /tmp/6125-x05TpS.stdout failed
>
> svg2png failed
>
>
>
> Que faire ?
>
> Merci,
>
> Axel
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>
>
> 
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>   



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Olivier Boudet]

Hello,

(inkscape:21965): WARNING **: GC Warning: Out of Memory!

Que faire ? Acheter de la RAM je crois...

On Mon, Jul 28, 2008 at 12:34 PM, Axel R. <[EMAIL PROTECTED]> wrote:

> Bonjour,
> En essayant de faire un rendu du sud de Paris, mon [EMAIL PROTECTED] se plante
> avec le message suivant :
>
> Updated to revision 9317.
> [#1   0% jobinit] Doing tileset 2074,1409 (zoom 12) (area around
> 48.835789,2.329102)
> [#1   0% Preproc] Downloading: Map data for captionless,default,maplint
> to /tmp/[#1   3% default] Rendering...
> ERROR  The following command
> produced an error message:
>  LC_ALL=C nice -n10 "inkscape" -z -w 1024 -h 256
> --export-area=0.00:658.661491:878.91:878.215322
> --export-png="/tmp/6125/6125_part-AKOVC2.png" "/tmp/output-6125-z14.svg"
>  > /tmp/6125-x05TpS.stdout
>  Debug output follows:
>  |
>  | ** (inkscape:21965): WARNING **: GC Warning: Repeated allocation of
> very large block (appr. size 16384):
>  | May lead to memory leak and poor performance.
>  |
>  |
>  | ** (inkscape:21965): WARNING **: GC Warning: Out of Memory!
> Returning NIL!
>  |
>  | terminate called after throwing an instance of 'std::bad_alloc'
>  |   what():  std::bad_alloc
>  |
>  | Emergency save activated!
>  | Emergency save completed. Inkscape will close now.
>  | If you can reproduce this crash, please file a bug at www.inkscape.org
>  | with a detailed description of the steps leading to the crash, so we
> can fix it.
>  | ** Message: Error: Inkscape encountered an internal error and will
> close now.
>  |
>  | Aborted
>
> Additional info about the Error(s):
>
>
> [#1   3% default] LC_ALL=C nice -n10 "inkscape" -z -w 1024 -h 256
> --export-area=0.00:658.661491:878.91:878.215322
> --export-png="/tmp/6125/6125_part-AKOVC2.png" "/tmp/output-6125-z14.svg"
>  > /tmp/6125-x05TpS.stdout failed
>
> svg2png failed
>
>
>
> Que faire ?
>
> Merci,
>
> Axel
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Bug de rendu

[Gwenn]

>   | ** (inkscape:21965): WARNING **: GC Warning: Out of Memory!  
> 
> Que faire ?

Acheter de la RAM ?

-- 
Gwenn

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

[OSM-talk-fr] Bug de rendu

[Axel R.]

Bonjour,
En essayant de faire un rendu du sud de Paris, mon [EMAIL PROTECTED] se plante 
avec le message suivant :

Updated to revision 9317.
[#1   0% jobinit] Doing tileset 2074,1409 (zoom 12) (area around 
48.835789,2.329102)
[#1   0% Preproc] Downloading: Map data for captionless,default,maplint 
to /tmp/[#1   3% default] Rendering... 
ERROR  The following command 
produced an error message:
  LC_ALL=C nice -n10 "inkscape" -z -w 1024 -h 256 
--export-area=0.00:658.661491:878.91:878.215322 
--export-png="/tmp/6125/6125_part-AKOVC2.png" "/tmp/output-6125-z14.svg" 
 > /tmp/6125-x05TpS.stdout
  Debug output follows:
  |
  | ** (inkscape:21965): WARNING **: GC Warning: Repeated allocation of 
very large block (appr. size 16384):
  | May lead to memory leak and poor performance.
  |
  |
  | ** (inkscape:21965): WARNING **: GC Warning: Out of Memory!  
Returning NIL!
  |
  | terminate called after throwing an instance of 'std::bad_alloc'
  |   what():  std::bad_alloc
  |
  | Emergency save activated!
  | Emergency save completed. Inkscape will close now.
  | If you can reproduce this crash, please file a bug at www.inkscape.org
  | with a detailed description of the steps leading to the crash, so we 
can fix it.
  | ** Message: Error: Inkscape encountered an internal error and will 
close now.
  |
  | Aborted

Additional info about the Error(s):


[#1   3% default] LC_ALL=C nice -n10 "inkscape" -z -w 1024 -h 256 
--export-area=0.00:658.661491:878.91:878.215322 
--export-png="/tmp/6125/6125_part-AKOVC2.png" "/tmp/output-6125-z14.svg" 
 > /tmp/6125-x05TpS.stdout failed

svg2png failed



Que faire ?

Merci,

Axel



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr