[OSM-dev-fr] Styles Mapnik gérés par CartoCSS - question existentielle
Bonjour,
Résumé rapide : Je suis en train de mettre en oeuvre sur les serveurs de
l'association osm-france un nouveau style de rendu sur la terre dont la cible
est le contributeur openstreetmap pour qu'il puisse voir :
- tout ou presque ce qu'il y a dans la base (tout objet dont les tags sont
acceptés sur le wiki)
- rapidement ses propre modifs
- créé collaborativement si quelqu'un veut m'aider
Son petit nom :
2u : acronyme de Ugly and Usefull
(J'aurais aimé l'appelé 4u, mais je n'ai pas trouvé les 2 u qui me manque)
Voilà pour le background, maintenant je me pose la question de la technologie
à utiliser.
Le moteur de rendu sera mapnik, et la base : osm2pgsql. Plutôt que de partir
de rien, je préfère reprendre le style existant sur osm.org (ou un autre,
tant qu'il est déjà bien avancé)
Je me suis donc naturellement tourné vers :
https://github.com/gravitystorm/openstreetmap-carto
Une reprise des styles actuels de osm.org qui sont au format xml vers le
format CartoCSS
La pub est alléchante :
- quasi identique à l'actuel sur osm.org
- joli format plus facile à écrire proche du CSS
- moins de redondance dans le style
- une interface graphique clic-clic pour faire ses modifs
- un générateur simple pour passer de cartoCSS à xml (dont mapnik a toujours
besoin)
Que demande le peuple ? un enfant s'en servirait dirait presque la pub, idéal
donc pour se partager le travail sans être informaticien et que de temps
gagné !
J'ai donc sauté dans la fosse (aux lions) de cette alléchante perspective,
mais voilà que la réalité semble rattraper quelque peu la fiction, et mes 4
heures à étudier la question et tester la solution dans tous les sens m'ont
amené à douté de mon choix.
J'en appel donc à ceux qui l'utilise, ceux qui utilisent autre chose, ceux qui
sont restés au bon vieux format xml d'avant, vous en pensez quoi ?
J'ai aussi sans doute du rater plein de trucs, et si vous avez un conseil, je
suis preneur, voilà mon pessimiste résumé :
_gain de temps_
* Je connais déjà pas mal le format xml et ça m'obligerais à apprendre un
nouveau format
* Le style osm.org à l'ancienne en fichier xml a tout de même bien évolué en
4 ans, et les fichiers sont maintenant séparés par thème, la redondance est
pas mal évitée par les xml entities et quelques tests m'ont montrés que
c'était tout à fait possible de continuer à travailler directement sur eux
_fiabilité_
* Le style xml est ancien, éprouvé, et bien testé
_pérennité_
* Ça, la pub ne le dit pas, mais cartoCSS ne permet pas toute la richesse du
format xml (il ne manque pas grand chose toutefois)
* lorsque mapnik évolue, il faut que cartoCSS suive, sinon, on ne peut pas
profiter des nouvelles fonctionnalités
* Si cartoCSS est abandonné, je suis bloqué
_facilité d'utilisation_
* Finalement, un enfant ne s'en servirait peut-être pas, le truc qui passe de
cartoCSS à xml est un obscure (pour moi) bidule en Node.js dont je n'ai pas
réussi à trouver de paquet debian et bourré de dépendances
(ma philosophie à 2 francs CFA : quand pas de paquet debian maintenu, méfiance
accrue)
* Le truc clic-clic qu'il est trop beau est bien gentil, mais il faut quand
même monter une base postgresql+osm2pgsql donc pour le accès à tout le
monde c'est pas non plus la panacée
* Le TileMill (le truc clic-clic) ne tourne que sur Ubuntu, et pas sur toutes
les versions, et avec un installateur louche qui va chercher des trucs et des
bidules un peu partout qui ne sont pas des les repos de la distrib, ce qui
amène à ne plus pouvoir, ou plus difficilement, traiter le style sur le
serveur directement
Bref de chez bref, ça fait, il me semble, un sacré potentiel à emmerde, pour
finalement gagner quoi ? un peu de confort à écrire des styles.
Le format du fichier .mml est symptomatique d'un mode de pensé, selon moi
tordu, des développeurs hypes et modernes qui adorent toucher toutes les
technos du moment et délaisseront le projet dans 3 ans par manque d'intérêt.
C'est au format JSON, le but est de rendre plus lisible le même fichier en xml
de mapnik, j'ai lu les deux [1] et [2], et je ne vois pas en quoi le json
(technologie que j'exècre par sa volonté de supplanter xml sans rien apporter
de probant) apporte quelque chose de vraiment incroyable, par contre, ce que
je vois bien, c'est que ça fait un nouveau format incompatible et une
nouvelle sur-couche qu'il faudra ré-écrire en xml si on change d'avis.
A votre avis ? Je suis tenté aussi par MapCSS et Caskadenik qui me semblent se
situer à mi-chemin.
[1]
Layer: [
{
geometry: polygon,
extent: [
-179.9692067183,
-85.051,
179.9692067183,
83.6693329998
],
id: world,
class: ,
Datasource: {
file:
/usr/local/share/mapnik/shape-resources/world_boundaries/shoreline_300.shp
},
srs-name: 900913,
srs: +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0
+y_0=0.0 +k=1.0 +units=m +nadgrids=@null +wktext
Re: [OSM-dev-fr] Styles Mapnik gérés par CartoCSS - question existentielle
Le 21 décembre 2012 12:52, sly (sylvain letuffe) li...@letuffe.org a écrit : Son petit nom : 2u : acronyme de Ugly and Usefull (J'aurais aimé l'appelé 4u, mais je n'ai pas trouvé les 2 u qui me manque) Ugly, Unneeded, Ubiquitous and Useful On a encore: Universal si Unneeded ne plait pas, mais c'est un peu redondant avec Ubiquitous. Et: Ultrasonic si Ugly est trop négatif, voire Underground si tu veux insister sur l'aspect mystérieux... Suggestions assez complètes sur: http://fr.wiktionary.org/w/index.php?title=Cat%C3%A9gorie:Adjectifs_en_anglaisfrom=u#mw-pages ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Styles Mapnik gérés par CartoCSS - question existentielle
Salut,
Sur osm7 j'ai installé un TileMill depuis les sources. Il apporte
quand même un gros confort dans le design du style.
Le mss j'ai envie de dire on s'en fout, c'est n'est pas la partie
intéressante. C'est surtout l'approche css-like qui est intéressante
(et donc cartocss).
Frédéric.
Le 21 décembre 2012 12:52, sly (sylvain letuffe) li...@letuffe.org a écrit :
Bonjour,
Résumé rapide : Je suis en train de mettre en oeuvre sur les serveurs de
l'association osm-france un nouveau style de rendu sur la terre dont la cible
est le contributeur openstreetmap pour qu'il puisse voir :
- tout ou presque ce qu'il y a dans la base (tout objet dont les tags sont
acceptés sur le wiki)
- rapidement ses propre modifs
- créé collaborativement si quelqu'un veut m'aider
Son petit nom :
2u : acronyme de Ugly and Usefull
(J'aurais aimé l'appelé 4u, mais je n'ai pas trouvé les 2 u qui me manque)
Voilà pour le background, maintenant je me pose la question de la technologie
à utiliser.
Le moteur de rendu sera mapnik, et la base : osm2pgsql. Plutôt que de partir
de rien, je préfère reprendre le style existant sur osm.org (ou un autre,
tant qu'il est déjà bien avancé)
Je me suis donc naturellement tourné vers :
https://github.com/gravitystorm/openstreetmap-carto
Une reprise des styles actuels de osm.org qui sont au format xml vers le
format CartoCSS
La pub est alléchante :
- quasi identique à l'actuel sur osm.org
- joli format plus facile à écrire proche du CSS
- moins de redondance dans le style
- une interface graphique clic-clic pour faire ses modifs
- un générateur simple pour passer de cartoCSS à xml (dont mapnik a toujours
besoin)
Que demande le peuple ? un enfant s'en servirait dirait presque la pub, idéal
donc pour se partager le travail sans être informaticien et que de temps
gagné !
J'ai donc sauté dans la fosse (aux lions) de cette alléchante perspective,
mais voilà que la réalité semble rattraper quelque peu la fiction, et mes 4
heures à étudier la question et tester la solution dans tous les sens m'ont
amené à douté de mon choix.
J'en appel donc à ceux qui l'utilise, ceux qui utilisent autre chose, ceux qui
sont restés au bon vieux format xml d'avant, vous en pensez quoi ?
J'ai aussi sans doute du rater plein de trucs, et si vous avez un conseil, je
suis preneur, voilà mon pessimiste résumé :
_gain de temps_
* Je connais déjà pas mal le format xml et ça m'obligerais à apprendre un
nouveau format
* Le style osm.org à l'ancienne en fichier xml a tout de même bien évolué en
4 ans, et les fichiers sont maintenant séparés par thème, la redondance est
pas mal évitée par les xml entities et quelques tests m'ont montrés que
c'était tout à fait possible de continuer à travailler directement sur eux
_fiabilité_
* Le style xml est ancien, éprouvé, et bien testé
_pérennité_
* Ça, la pub ne le dit pas, mais cartoCSS ne permet pas toute la richesse du
format xml (il ne manque pas grand chose toutefois)
* lorsque mapnik évolue, il faut que cartoCSS suive, sinon, on ne peut pas
profiter des nouvelles fonctionnalités
* Si cartoCSS est abandonné, je suis bloqué
_facilité d'utilisation_
* Finalement, un enfant ne s'en servirait peut-être pas, le truc qui passe de
cartoCSS à xml est un obscure (pour moi) bidule en Node.js dont je n'ai pas
réussi à trouver de paquet debian et bourré de dépendances
(ma philosophie à 2 francs CFA : quand pas de paquet debian maintenu, méfiance
accrue)
* Le truc clic-clic qu'il est trop beau est bien gentil, mais il faut quand
même monter une base postgresql+osm2pgsql donc pour le accès à tout le
monde c'est pas non plus la panacée
* Le TileMill (le truc clic-clic) ne tourne que sur Ubuntu, et pas sur toutes
les versions, et avec un installateur louche qui va chercher des trucs et des
bidules un peu partout qui ne sont pas des les repos de la distrib, ce qui
amène à ne plus pouvoir, ou plus difficilement, traiter le style sur le
serveur directement
Bref de chez bref, ça fait, il me semble, un sacré potentiel à emmerde, pour
finalement gagner quoi ? un peu de confort à écrire des styles.
Le format du fichier .mml est symptomatique d'un mode de pensé, selon moi
tordu, des développeurs hypes et modernes qui adorent toucher toutes les
technos du moment et délaisseront le projet dans 3 ans par manque d'intérêt.
C'est au format JSON, le but est de rendre plus lisible le même fichier en xml
de mapnik, j'ai lu les deux [1] et [2], et je ne vois pas en quoi le json
(technologie que j'exècre par sa volonté de supplanter xml sans rien apporter
de probant) apporte quelque chose de vraiment incroyable, par contre, ce que
je vois bien, c'est que ça fait un nouveau format incompatible et une
nouvelle sur-couche qu'il faudra ré-écrire en xml si on change d'avis.
A votre avis ? Je suis tenté aussi par MapCSS et Caskadenik qui me semblent se
situer à mi-chemin.
[1]
Layer: [
{
geometry: polygon,
extent:
Re: [OSM-dev-fr] Styles Mapnik gérés par CartoCSS - question existentielle
Le 21 décembre 2012 12:52, sly (sylvain letuffe) li...@letuffe.org a écrit : Bonjour, Résumé rapide : Je suis en train de mettre en oeuvre sur les serveurs de l'association osm-france un nouveau style de rendu sur la terre dont la cible est le contributeur openstreetmap pour qu'il puisse voir : - tout ou presque ce qu'il y a dans la base (tout objet dont les tags sont acceptés sur le wiki) - rapidement ses propre modifs - créé collaborativement si quelqu'un veut m'aider Son petit nom : 2u : acronyme de Ugly and Usefull (J'aurais aimé l'appelé 4u, mais je n'ai pas trouvé les 2 u qui me manque) Ultra Ugly but Ultra Useful ;) Voilà pour le background, maintenant je me pose la question de la technologie à utiliser. Le moteur de rendu sera mapnik, et la base : osm2pgsql. Plutôt que de partir de rien, je préfère reprendre le style existant sur osm.org (ou un autre, tant qu'il est déjà bien avancé) Je me suis donc naturellement tourné vers : https://github.com/gravitystorm/openstreetmap-carto Une reprise des styles actuels de osm.org qui sont au format xml vers le format CartoCSS La pub est alléchante : - quasi identique à l'actuel sur osm.org - joli format plus facile à écrire proche du CSS - moins de redondance dans le style - une interface graphique clic-clic pour faire ses modifs - un générateur simple pour passer de cartoCSS à xml (dont mapnik a toujours besoin) Que demande le peuple ? un enfant s'en servirait dirait presque la pub, idéal donc pour se partager le travail sans être informaticien et que de temps gagné ! J'ai donc sauté dans la fosse (aux lions) de cette alléchante perspective, mais voilà que la réalité semble rattraper quelque peu la fiction, et mes 4 heures à étudier la question et tester la solution dans tous les sens m'ont amené à douté de mon choix. J'en appel donc à ceux qui l'utilise, ceux qui utilisent autre chose, ceux qui sont restés au bon vieux format xml d'avant, vous en pensez quoi ? J'ai aussi sans doute du rater plein de trucs, et si vous avez un conseil, je suis preneur, voilà mon pessimiste résumé : _gain de temps_ * Je connais déjà pas mal le format xml et ça m'obligerais à apprendre un nouveau format * Le style osm.org à l'ancienne en fichier xml a tout de même bien évolué en 4 ans, et les fichiers sont maintenant séparés par thème, la redondance est pas mal évitée par les xml entities et quelques tests m'ont montrés que c'était tout à fait possible de continuer à travailler directement sur eux _fiabilité_ * Le style xml est ancien, éprouvé, et bien testé _pérennité_ * Ça, la pub ne le dit pas, mais cartoCSS ne permet pas toute la richesse du format xml (il ne manque pas grand chose toutefois) * lorsque mapnik évolue, il faut que cartoCSS suive, sinon, on ne peut pas profiter des nouvelles fonctionnalités * Si cartoCSS est abandonné, je suis bloqué CartoCSS génère des XML, tu pourra repartir de ceux-ci, non ? Ils ne seront sûrement pas aussi clean qu'écrits directement, mais ce n'est pas une impasse. _facilité d'utilisation_ * Finalement, un enfant ne s'en servirait peut-être pas, le truc qui passe de cartoCSS à xml est un obscure (pour moi) bidule en Node.js dont je n'ai pas réussi à trouver de paquet debian et bourré de dépendances (ma philosophie à 2 francs CFA : quand pas de paquet debian maintenu, méfiance accrue) * Le truc clic-clic qu'il est trop beau est bien gentil, mais il faut quand même monter une base postgresql+osm2pgsql donc pour le accès à tout le monde c'est pas non plus la panacée * Le TileMill (le truc clic-clic) ne tourne que sur Ubuntu, et pas sur toutes les versions, et avec un installateur louche qui va chercher des trucs et des bidules un peu partout qui ne sont pas des les repos de la distrib, ce qui amène à ne plus pouvoir, ou plus difficilement, traiter le style sur le serveur directement Ca tourne aussi sur Mac, c'est en fait une appli web (HTML5/JS), qu'on pourrait très bien faire tourner sur un serveur et pas en local. Bref de chez bref, ça fait, il me semble, un sacré potentiel à emmerde, pour finalement gagner quoi ? un peu de confort à écrire des styles. Le format du fichier .mml est symptomatique d'un mode de pensé, selon moi tordu, des développeurs hypes et modernes qui adorent toucher toutes les technos du moment et délaisseront le projet dans 3 ans par manque d'intérêt. C'est au format JSON, le but est de rendre plus lisible le même fichier en xml de mapnik, j'ai lu les deux [1] et [2], et je ne vois pas en quoi le json (technologie que j'exècre par sa volonté de supplanter xml sans rien apporter de probant) apporte quelque chose de vraiment incroyable, par contre, ce que je vois bien, c'est que ça fait un nouveau format incompatible et une nouvelle sur-couche qu'il faudra ré-écrire en xml si on change d'avis. A votre avis ? Je suis tenté aussi par MapCSS et Caskadenik qui me semblent se situer à mi-chemin. JSON est un choix de
Re: [OSM-dev-fr] Styles Mapnik gérés par CartoCSS - question existentielle
Le 21 décembre 2012 14:15, Pieren pier...@gmail.com a écrit : Mouais. Je crois avoir lu la même chose à chaque fois qu'un nouveau format est sorti (xml, json, etc). Difficile de dire à l'avance si ça marchera ou pas. Il y a aussi, c'est sûr, des effets de mode. (...) Le succès croissant de JSON par rapport à XML est indéniable. Et ce n'est pas juste un « effet de mode », car il y a de sérieux appuis dans les standards du web. Même Unicode s'y met en proposant (depuis peu) sa base CLDR aussi en format JSON au lieu de seulement XML/LDML. En particulier, il y a une une meilleure intégration dans les navigateurs, avec une implémentation native et plus sécurisée que le XML (qui est un peu trop ouvert avec son support des DTD et des références externes et à cause de son extensibilité très permissive par les namespaces), et une syntaxe nettement plus verbeuse et plus compliquée à parser que le JSON, qui offre pratiquement les mêmes possibilités ontologiques même si le schéma de données doit être adapté par une convention de traduction supplémentaire). De plus en plus les sites utilisent les JSONRequests au lieu des classiques XMLHttpRequests : c'est plus rapide et plus facile à programmer et utiliser en Javascript/ECMAScript et même dans d'autres langages. Il n'y a plus de dépendance avec les anciennes XMLHttpRequests (très peu sécurisées d'Internet Explorer, utilisant dans le passé un composant ActiveX pour s'interfacer). Même sur un vieux navigateur qui n'aurait pas de parser JSON intégré, on peut encore en monter un en Javascript (en utilisant soit les anciennes XMLHttpRequest pour l'interrogation du serveur, soit les nouvelles WebSockets), et sécuriser ce Javascript adaptateur facilement (contre les attaques de type injection de code Javascript), sans dégradation notable de performance (car un parser JSON est très simple à écrire, même en Javascript). ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Styles Mapnik gérés par CartoCSS - question existentielle
On vendredi 21 décembre 2012, Pieren wrote:
qui a totalement disqualifié cet outil pour Andy Allan (celui qui a créé le
style cyclemap et lancé la convertion du style osm vers cartoCSS).
Certes, disqualifié également donc.
Sauf que si je ne m'abuse :
https://github.com/mapnik/Cascadenik/blob/master/AUTHORS.txt
http://wiki.openstreetmap.org/wiki/Cascadenik
On retrouve dans les auteurs des gens connus de cartoCSS maintenant (de chez
mapbox par exemple)
qui ont choisi, que plutôt de reprendre cascadenik, de forker en quelque
sorte et refaire autre chose. Ma crainte est donc :
même gens + même fonctionnalités + même société = même fin tragique
Mon avis sera très différent si le support de cartoCSS était intégré à mapnik,
là, ça aurait une autre crédibilité pour la pérénité.
Tu parles de carto ?
https://npmjs.org/package/carto
http://wiki.openstreetmap.org/wiki/Carto
yes
Il y a quand même des avantages comme l'utilisation de variables (une
seule définition de la couleur de l'eau par exemple).
C'est pas tant les avantages d'une approche CSS qui m'inquiètes (d'ailleurs
c'est bien pour ça que j'hésite car c'est super génial)
Les variables sont possibles en xml également par le système d'entité, mais la
force en +, c'est le cascading de style : un highway=secondary de zoom 14
hérite des propriétés du highway, du secondary, et du zoom 14 et ça factorise
donc énormément.
presque hs
Mouais. Je crois avoir lu la même chose à chaque fois qu'un nouveau
format est sorti (xml, json, etc). Difficile de dire à l'avance si ça
marchera ou pas.
Je ne me souviens pas avoir entendu grommeler à propos de html puis xml,
avant, c'était soit des formats protégés, binaires et mal supportés ou des
formats largement trop basiques comme csv
xml s'est rapidement imposé un peu partout car il comblait un manque terrible
et son approche généraliste permet une grande ré-utilisation et dispose d'un
important support applicatif de ce fait.
json, ça apporte quoi par rapport à ça ? A part des allergiques aux balises
qui préfère les { } ?
(note que j'aurais dis exactement la même chose de xml s'il était venu après
json)
Je la cite souvent en ce moment : http://xkcd.com/927/ mais c'est pas prêt
d'être obsolète
/presque hs
Il y a aussi, c'est sûr, des effets de mode. Mais un critère important
selon moi est que le style principal d'osm.org basculera tôt ou tard
vers cartoCSS, que celui-ci a une équipe derrière, celle de mapbox,
qui est aussi celle qui continue de supporter mapnik. Donc cartoCSS,
tilemill, mapnik, c'est une chaîne qui se tient ensemble (et qui est
open-source) et qui va continuer de s'améliorer dans les prochains
temps.
Puisses-tu dire vrai, 2 avis contre mon doute, je me jette dans la fosse aux
lions...
--
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Styles Mapnik gérés par CartoCSS - question existentielle
On vendredi 21 décembre 2012, Christian Quest wrote: CartoCSS génère des XML, tu pourra repartir de ceux-ci, non ? Ils ne seront sûrement pas aussi clean qu'écrits directement, mais ce n'est pas une impasse. Un 1/2 point pour toi. J'imagine que oui, on peut toujours repartir de ça, mais j'attends de faire quelque tests de compilation, je suppose que tout va être déplier, et dé-normalisé, donc pour repartir de ça ! c'est comme reprendre un fichier html généré par dreamweaver ;-) -- sly, DWG member since 11/2012 Coordinateur du groupe [ga] http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Styles Mapnik gérés par CartoCSS - question existentielle
Le vendredi 21 décembre 2012 12:52:37 sly a écrit : J'en appel donc à ceux qui l'utilise, ceux qui utilisent autre chose, ceux qui sont restés au bon vieux format xml d'avant, vous en pensez quoi ? Moi perso ça fait un bail que j'ai pas fait de rendu mapnik, mais j'avais opté pour tout faire en python. Du coup, je m'étais fait une API pour ajouter une couche en un ligne de code indiquant la requête et le style avec des variables permettant de factoriser à outrance. Ça m'allait bien pour les quelques couches que j'avais à gérer, car gérer tout ce XML ça me gavait. Maintenant pour ton projet, faire un style très riche ça va pas être une mince affaire. D'un point de vue concret, je trouve de plus en plus pratique et pertinent d'utiliser l'overpass pour visualiser des données particulières. Ça a l'air intéressant openstreetmap-carto, je ne connaissais pas. Merci -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
[OSM-dev] FW: Screenshots from OpenStreetMap-Carto spot checking
(Let's see if my bounce issues are resolved) -Original Message- From: Ed Loach [mailto:e...@loach.me.uk] Sent: 20 December 2012 08:46 To: 'Toby Murray'; 'dev List' Subject: RE: [OSM-dev] Screenshots from OpenStreetMap-Carto spot checking Toby wrote: I was doing some poking around yesterday and noticed that county borders (admin_levl=6) aren't being rendered at zoom 9 and 10. The wiki instructions for administrative boundaries are designed I think to help renderers at whatever point in time the instructions were written. Each boundary relation is meant to have the boundary=administrative tag and the correct admin level tag. Each way is also meant to have the boundary=administrative tag and the lowest value of admin_level (so a boundary which is a member of say admin level 4,5,6,8 relations would get 4). I have always assumed that the way tags are only there to make things easier for renderers as in theory it can also be determined from the relations the way is a member of. If it is possible, this carto switch might be a good time to make the relation tagged levels take priority and the way tags unnecessary for relation based boundaries (though perhaps still relevant for boundary ways that aren't in relations). I've spent quite a bit of time in the past trying to keep the GB boundary tags in line with the wiki documentation, though haven't bothered recently: http://www.loach.me.uk/osm/boundaries/misc.aspx Ed ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Android 3D mapping with OSM
Hello, I made an announcement in SOTM Tokyo that Nutiteq 3D mapping SDK for Android will be free for OSM community. It is not (yet at least) good enough to be fully open source, but it is good enough for general use. So, here it comes as a holiday gift*, our 1+ year of development efforts. From the Wiki page [1] you can find how to replace Nutiteq logo with OSM logo, and there are also other guides for different map layer options, including vector rendering, 3D models on map etc. Please use our development list [2] for any feedback, suggestions, questions etc. Contact me for (commercial) support. [1] https://github.com/nutiteq/hellomap3d/wiki/Free-openstreetmap-license [2] https://groups.google.com/forum/#!forum/nutiteq-dev -- Jaak Laineste * - offer is valid until end of the world only ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Planet.osm delayed
Dev, planet-121219.osm.bz2 dump process failed and the files have been removed from http://planet.osm.org/ planet-121221.osm.bz2 will be available late Sunday or early Monday. Regards Grant ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Planet.osm delayed
Hi Grant, On a not-so-unrelated note - when is the next full history dump planned? Paweł ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Planet.osm delayed
May I wish for line feeds similar to the regular planet also in the full history one? Would make processing with standard tools like grep possible. Size should not be the problem. I expect it to compress similar well. And for compact storage there is pbf as well. Stephan Paweł Paprota ppa...@fastmail.fm wrote: Hi Grant, On a not-so-unrelated note - when is the next full history dump planned? Paweł ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] iD alpha0
Hey all, Happy to announce that early tomorrow we're tagging an alpha0 release of iD for testing development: http://mapbox.com/osmdev/2012/12/22/alpha0/ As you all know, creating an editor is a very big effort and there's still a long way to go. What this mostly means is that we're happy with this set of features being good for an alpha release series, working on stability, and then adding a lot of great stuff (powerful presets) when we enter beta. On a technical level, it also means that development is shifting from our intense-but-enjoyable regime of working in the master branch to working in feature and bugfix branches and trying to keep master in a continually-improving state. And that we are, as much as ever, excited for any new contributors to join. A big thanks to Saman, John, Alex, Richard, Martin and more for their work towards this point. Tom ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] iD alpha0
W0-oo-0t! On Fri, Dec 21, 2012 at 3:24 PM, Tom MacWright t...@macwright.org wrote: Saman, John, Alex, Richard, Martin -- Jeff Meyer Global World History Atlas www.gwhat.org j...@gwhat.org 206-676-2347 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
