Re: [OSM-dev] Kosmtik rendering issues
We had a similar discussion on the Github issues some days ago: https://github.com/gravitystorm/openstreetmap-carto/issues/657#issuecomment-78665177 I was not able to really determine the origin of this difference, but the main suspicion is a difference in the used Mapnik. Of course, it can also be a bug on Kosmtik ;) I've create an issue on the Kosmtik side to track any more info one of you may have: https://github.com/kosmtik/kosmtik/issues/57 I was in a field mission in Jordan, so I was not really active on this issue, and I'm sorry for that. I'm back from today, I'm expecting a speed week now, but then I'll have a bit more time to dig in if still needed. Also, side note, to compare renderings, I suggest this kosmtik plugin: https://github.com/kosmtik/kosmtik-map-compare Cheers, Yohan On 06/04/2015 12:42, Markus Mayr wrote: This is strange. It looks like some kind of scaling issue. Different Mapnik-Version? (mine is 2.3.0-pre ) Something like a negative-retina-tile parameter (somewhere)? Am 2015-04-06 um 09:59 schrieb nebulon42: This is what I got: http://i.imgur.com/isBTDCJ.jpg osm.org is much sharper. Am 2015-04-05 um 22:59 schrieb Markus Mayr: Same here. This screenshot displays my situation: http://i.imgur.com/HXBNP7W.png Am 2015-04-05 um 16:49 schrieb Matthijs Melissen: On 5 April 2015 at 13:21, nebulon42 nebulo...@yandex.com wrote: I started playing around with Kosmtik instead of TileMill. So far it works well, but I'm having two issues with the rendering: * Labels and symbols are cut off at metatile borders. As far as I understand there needs to be a metatile buffer. How can I set this in the config options? I can confirm this issue, and I don't currently have a solution. * Compared to openstreetmap.org my local tiles are more blurry. What can cause this? Or did I miss osm.org switching to high-res tiles? This I cannot reproduce. Is everything more blurry, or certain elements only? -- Matthijs ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev-fr] Ajouter le Nicaragua dans Osmose?
Hello, Je sais pas si je suis sûr la bonne liste, mais je sais qu'ici je trouverai nos deux loulous d'Osmose :) Des collègues d'HOT actuellement au Nicaragua me demande s'il serait possible d'ajouter le pays à Osmose. Merci d'avance pour eux si c'est possible :) Yohan ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev] LeafletJS strange behaviour with OSM layer
Sounds like the container of your map has changed after its initialization.
Try calling map.invalidateSize() when the container has its definitive size.
Yohan
On 09/06/2013 08:51 PM, François Lacombe wrote:
Hi,
I'm currently trying to switch to OSM (from Google Maps) on several
pages apps of my website.
All is working fine with leafletJS but some of my apps doesn't get all
tiles loaded.
You can find an example here :
http://www.infos-reseaux.com/apps/ADSLObs/carte-nra-nro/?domain_id=FT
Only one row of tiles is loaded at the top of my map frame and I need to
drag down it to see other tiles on my screen.
The div where leaflet is build received this css :
.app-webVRD-gMapsContainer {
background-color:#FF;
height:600px;
min-height:600px;
width:100%;
min-width:100%;
}
Here is the leaflet init JS :
// Conteneur
_MAP = L.map(gmaps_container_id, {
doubleClickZoom:false,
scrollWheelZoom:true
});
// Couche OSM
L.tileLayer('http://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png
http://tile.openstreetmap.org/{z}/{x}/{y}.png', {
attribution: 'Map data © OpenStreetMap contributors',
maxZoom: 18,
minZoom:1
}).addTo(_MAP);
I'm working on firefox 23.0.1, I get the same on Chrome and IE.
Thank you in advance for any tip about this problem.
Cheers.
*François Lacombe*
francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev-fr] Paratage de DEM ( était Héberger le rendu HOT?)
On 06/30/2013 08:20 PM, Jérôme Cornet wrote: Juste quelques questions en vrac: - Pas tout compris l'objectif: ça serait d'avoir un serveur de DEM utilisable plus ou moins par tout le monde? Je sais pas répondre à la question, mais je sais qu'on a une réunion tech IRC demain soir à 19 heures pour discuter notamment de ça ;) Sinon, en très gros l'idée est surtout de se dire que, vu qu'on est plusieurs à avoir besoin de DEM, autant mutualiser nos efforts autant que possible, vu ce que c'est coûteux en temps et énergie comme process. ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Paratage de DEM ( était Héberger le rendu HOT?)
On 06/28/2013 07:43 PM, sly (sylvain letuffe) wrote: On vendredi 28 juin 2013, Christian Quest wrote: Vous pensez que ça vaudrait le coup de récupérer des DEM locaux ? Je dirais délicat de répondre : En terme de résultat final que l'on peut attendre pour l'utilisateur, ça me semble évident que ça serait génial. Même si ça fait un patchwork de zones très bien représentées et d'autres plus grossières, je pense que ça serait un réél plus. Mais je vois poindre un travail de titan qui consiste à uniformiser les formats, faire les demandes, fusionner tout çà en un tout utilisable, casse tête des licences, etc. Je dirais dur d'estimer le travail nécessaire, même si ça pourrait sans doute faire des heureux bien au delà d'osm ! C'est clairement un travail de titan. Mais si: - on commence par une couverture mondiale correcte en partant d'une des sources principales (plutôt ASTER au vu des dernières discussions) sans chercher à faire des miracles - on se met d'accord sur une taille de dalle idéale (1x1, 5x5...) - chacun y passe un peu de temps en fonction de ses intérêts, genre moi sur les zones couvertes par HOT, ou sur les plaines le long des fleuves navigables, Sly sur les montagnes, Jérôme sur le Sahara, untel parce qu'il a eu un jeu de données aux licences compatibles, etc. - on se fait un petit repo git avec les scripts utilisés qu'on fait évoluer alors je me dis que c'est un travail de titan raisonnable et je signe :) On commence quand? ;) ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Paratage de DEM ( était Héberger le rendu HOT?)
On 06/29/2013 01:59 PM, yvecai wrote: Quid de la résolution ? ASTER, c'est ~30m, SRTM ~90m, on a cité ici des extraits à 5m, Je dirais, sans éclat, qu'on prend le meilleur dispo quand on bosse sur une zone? Et à part aller sur le terrain, comment choisir un jeu ou l'autre ? Pas sûr qu'il y ait une stratégie gagnante à tous les coups. Plutôt: - on importe massivement une première fois en visant une qualité moyenne (on fait au mieux dans le cas d'un traitement à l'aveugle) - zone par zone qui nous intéresse, on se pose les bonnes questions et on fait le bon choix en fonction des données et connaissances qu'on a :) En gros, ce qui peut rendre le chantier acceptable, c'est justement qu'on n'attaque pas de front. On pose une base, et on améliore en fonction des projets. A priori, sur une zone déterminée, on sera raccord sur les objectifs: le plus fidèle et le plus précis, le mieux. D'ailleurs, vu la galère que ça l'air d'être d'importer ASTER pour le monde entier, on peut aussi zapper l'import massif initial. En gros, on se met d'accord sur les modalités de stockage (taille des dalles essentiellement), et on ajoute ce qui nous intéresse. Par exemple moi en l'état y a Haiti, l'Afrique de l'Ouest et l'Indonésie qui m'intéressent, j'ajoute, et tant pis si le reste du monde est sans relief. En parallèle, Sly ajoutera l'Europe qui l'intéresse, et paf tant mieux j'en profiterai. Ensuite Yves ajoutera les pays neigeux, et paf tout le monde en profite. L'autre avantage serait qu'on optimiserait le workflow au fur et à mesure et sur des volumes modestes. Plutôt que de tout se fader, et de se rendre compte ensuite que Ah mince, il faut ajouter -nodata xx ou se genre de blague. Bref: de mon point de vue, ça me semble acceptable de partir d'un DEM à trous qu'on améliore petit à petit. Des avis? ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Paratage de DEM ( était Héberger le rendu HOT?)
On 06/27/2013 03:40 PM, sly (sylvain letuffe) wrote: Côté calque hillshade, mon idée générale pour l'instant c'est d'utiliser un .vrt qui référence les tif moulinés, apparemment c'est ce qui se fait. Je ne travail pas sur le monde mais juste sur l'europe (780°²) et j'ai opté pour un seul et unique fichier tif (9Go) N'ayant pas trop fait d'essais avec la solution d'un vrt et d'une grosse arborescence, je ne saurais dire si c'est mieux ou moins bien. Si ce n'est sans doute que ma technique ajoute une monstre opération à base de gdal_merge.py pour produire un fichier titan. Sur ce point, j'ai eu des précisions d'Andy Allan (Gravitystorm, Thunderforest): lui il utilise carrément des dalles de 1x1 (donc des dizaines de milliers de fichiers) dans son vrt. Ce qui me fait dire qu'on doit pouvoir se passer de l'étape du merge dès lors qu'on utilise un vrt. ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Rendu françafrique
On 05/21/2013 10:10 PM, Jérôme Cornet wrote: Je n'ai pas encore rendu publique les feuilles Carto de rendu, mais si ça vous intéresse je peux vous les communiquer (je mettrais ça sur un github quand le problème de license sera réglé…) Moi ça m'intéresse :) Merci! Yo ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
[josm-dev] zip style using MapCSS
Hi! I'm working (with HOT) to create a new style for JOSM (which goal is to fit the Humanitarian Data Model [1] ). One of the needs is to provide more icons for POI regarding humanitarian situations. For this style, I'm using the MapCSS option, because I feel more confident with this syntax. Given that we will have many custom icons, and given that this style will mainly be used in humanitarian context with very poor Internet connection, the ideal should be to be able to provide a final ZIP, with the style and icons, that can be shared with USB key (as well as with an URL of course), and easy to install. The documentation [2] says that this can be done with a XML based style only. I've made a quick test of a zip with my style and icons, and in fact the style is read, but the icons are not found. Maybe I've done something bad, but given this quick failed attempt and given the actual documentation, I prefer to ask before going ahead. So: - is it possible to use a zip for a MapCSS style including icones? - if not, is it something that has a chance to be added in a future release of JOSM? Thanks for reading! Thanks for the good work on JOSM! Yohan [1] http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags [2] https://josm.openstreetmap.de/wiki/Styles#Iconhandling ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] zip style using MapCSS
Thanks, PierZen has also pointed me to a working example! Yohan On 04/15/2013 10:09 AM, Dirk Stöcker wrote: On Mon, 15 Apr 2013, Yohan Boniface wrote: The documentation [2] says that this can be done with a XML based style only. Where does it say so? Since JOSM revision 2289 zip files are supported. The zip file must contain at least one file with extension *xml*. Icon names and path are relative to the topmost zip directory. If there are multiple XML files, a file with style in the name is preferred (to allow packaging styles and presets in one archive). I've made a quick test of a zip with my style and icons, and in fact the style is read, but the icons are not found. Wrong path? Icon names and path are relative to the topmost zip directory. One example from Wiki including icons: http://josm.openstreetmap.de/josmfile?page=Styles/Landcoverzip Ciao ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[OSM-dev] Leaflet.EditInOSM
Hi all, A short mail to introduce the little plugin Leaflet.EditInOSM [1], which add a control in Leaflet with links to edit the current view in JOSM, Potlatch or iD. Demo here: http://yohanboniface.github.com/Leaflet.EditInOSM/ It's a very simple initial version, and many improvements can be done while needs raise, but it should cover the basic use cases. I've also added it optionally in uMap project, for example: http://umap.fluv.io/map/yohanboniface/anonymous-demo/ Test and feedback welcome. Feel free to contribute. Yohan [1] https://github.com/yohanboniface/Leaflet.EditInOSM ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] CartoCC: Carto/TileMill config customizer
Hi again, About simple tools I'm working on and can be useful for others, let me introduce another one that can be helpful for people working with TileMill: https://github.com/yohanboniface/CartoCC It aims to easily configure a project.mml file. Say for example to configure the local connection to a database or the path for some shape file. I'd like to make it a real TileMill plugin in the future, and find a way to help a versionned project.mml file workflow (not to pollute commits with changes related to the local environment). Of course it's open source, so fill free to use it, fork it, change it, pull request, or what else can happen to open code ;) Yohan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] uMap Project: OSM everywhere
On 01/06/2013 07:21 PM, Janko Mihelić wrote: This looks beautiful. Very easy to use, and that's most important. I'm bookmarking it and looking forward for new releases :) Thanks! :) A great feature would be the draw line along road like Google has. I'm not sure how that could be done without having your own router machine. Maybe borrowing OSRM-s routing capacity is possible? Damn, this one is not an easy one, but you're right, coupling with a router machine could be really useful. I flag the idea for future me :) [1] By the way, the last days, I've added some users suggestions: - GPX support for batch import - geolocation control (locate user using HTML5 API) - jump to location control (smart geocoding using Nominatim) Plus there is now a German translation and part of an italian one :) Thanks for tests, help and feedback! Yohan [1] for reference: https://github.com/yohanboniface/Leaflet.Storage/issues/23 Janko Mihelić 2013/1/3 Yohan Boniface yohanbonif...@free.fr mailto:yohanbonif...@free.fr Hi, This email for introducing the uMap project. TL;DR: http://umap.fluv.io/ (demo site). The goal of the project is to provide an app for easy creation of slippy maps for *non technical* end user, with POI, polygons, etc., and embed/share them all over the Big Internet. This project comes *without* any hosting service SaaS like: it just provides the app and will let interested people host (and customize) their own instances. It's in alpha state, I'm preparing the 0.1 release. Here are the already covered features: - create/edit/delete maps - choose the tile layers - add/edit/delete Markers, Polyline, Polygon - manage categories of POIs, to change icon or colors all at once - import GeoJSON and KML from a file or an URL - login/logout - manage permissions (choose who can edit: only owner, selected editors or everybody) - choose icon type - add pictograms to icons (closed list for now) - change icon color (from POI itself or for a group of POIs) - choose the licence of the datas - manage a caption for the map - get an iframe to spread the map - all is i18n compliant Nice features to add in the future: - import POIs from XAPI - upload custom icons - add download option for getting data in GeoJSON - better mobile UI - choose colors from a palette - ... About the modules: * Leaflet-Storage [1]: Leaflet plugin, built on top of Leaflet.Draw et Leaflet.Hash, handling all the client (JavaScript) part; it doesn't know nothing about the backend, so one can also create a Rails, Node or whatever backend * django-leaflet-storage [2]: Leaflet-Storage backend django powered; it's an app, so reusable out the uMap project * uMap [3]: Django project gluing the previous modules, which goal is only to have a plug'n play solution, with some more CSS than the default neutral modules How to help? - test on http://umap.fluv.io and add issues for bugs or enhancements - add new translations (only French has been done) - host an (alpha) instance - code (python, JavaScript, HTML, CSS... or other if one wants to create his own backend) :) Thanks in advance for feedback and help, Happy Open 2013! Yohan [1] https://github.com/__yohanboniface/Leaflet.Storage https://github.com/yohanboniface/Leaflet.Storage [2] https://github.com/__yohanboniface/django-leaflet-__storage https://github.com/yohanboniface/django-leaflet-storage [3] https://bitbucket.org/__yohanboniface/umap https://bitbucket.org/yohanboniface/umap _ talk mailing list t...@openstreetmap.org mailto:t...@openstreetmap.org http://lists.openstreetmap.__org/listinfo/talk http://lists.openstreetmap.org/listinfo/talk ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] uMap Project: OSM everywhere
Hi, This email for introducing the uMap project. TL;DR: http://umap.fluv.io/ (demo site). The goal of the project is to provide an app for easy creation of slippy maps for *non technical* end user, with POI, polygons, etc., and embed/share them all over the Big Internet. This project comes *without* any hosting service SaaS like: it just provides the app and will let interested people host (and customize) their own instances. It's in alpha state, I'm preparing the 0.1 release. Here are the already covered features: - create/edit/delete maps - choose the tile layers - add/edit/delete Markers, Polyline, Polygon - manage categories of POIs, to change icon or colors all at once - import GeoJSON and KML from a file or an URL - login/logout - manage permissions (choose who can edit: only owner, selected editors or everybody) - choose icon type - add pictograms to icons (closed list for now) - change icon color (from POI itself or for a group of POIs) - choose the licence of the datas - manage a caption for the map - get an iframe to spread the map - all is i18n compliant Nice features to add in the future: - import POIs from XAPI - upload custom icons - add download option for getting data in GeoJSON - better mobile UI - choose colors from a palette - ... About the modules: * Leaflet-Storage [1]: Leaflet plugin, built on top of Leaflet.Draw et Leaflet.Hash, handling all the client (JavaScript) part; it doesn't know nothing about the backend, so one can also create a Rails, Node or whatever backend * django-leaflet-storage [2]: Leaflet-Storage backend django powered; it's an app, so reusable out the uMap project * uMap [3]: Django project gluing the previous modules, which goal is only to have a plug'n play solution, with some more CSS than the default neutral modules How to help? - test on http://umap.fluv.io and add issues for bugs or enhancements - add new translations (only French has been done) - host an (alpha) instance - code (python, JavaScript, HTML, CSS... or other if one wants to create his own backend) :) Thanks in advance for feedback and help, Happy Open 2013! Yohan [1] https://github.com/yohanboniface/Leaflet.Storage [2] https://github.com/yohanboniface/django-leaflet-storage [3] https://bitbucket.org/yohanboniface/umap ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
