Re: [OSM-dev-fr] [OSM-talk-fr] Réseau routier du Cantal : c'est fait
Le jeudi 28 juin 2012 10:48:25 Nicolas Moyroud a écrit : Que contient plus précisément le fichier Cantal-routingInput.csv ? De ce que j'ai compris vous utilisez les enveloppes des communes issues du GEOFLA pour déterminer les points de départ et d'arrivée des itinéraires. Donc vos distances sont calculées à partir des frontières des communes. J'ai bon ? Non. Dans le fichier GeoFLA, il y a aussi les coordonnées du chef-lieu de commune. Donc le fichier en question contient la liste des trajets à calculer, avec pour chaque ligne, les coordonnées du point de départ et d'arrivée. Le chef-lieu est plus représentatif du centre des zone résidentielles d'une commune que le centroïdes de la limite administrative. Si tu as d'autres questions, on pourrait passer sur dev-fr Du coup, pourquoi n'avez-vous pas utilisé directement les limites de communes issues d'OSM ? Même si j'avais voulu, elles n'y sont pas pour toutes les communes ! -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] [OSM-talk-fr] Réseau routier du Cantal : c'est fait
OK merci pour ces claircissements, je comprends mieux. :-) Est-il prvu de mettre disposition les scripts python que vous avez ralis ? a+ Nicolas ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] [OSM-talk-fr] Réseau routier du Cantal : c'est fait
Le jeudi 28 juin 2012 11:05:37 Nicolas Moyroud a écrit : OK merci pour ces éclaircissements, je comprends mieux. :-) Est-il prévu de mettre à disposition les scripts python que vous avez réalisé ? Mais ils y sont :-) http://trac.clermont.cemagref.fr/svn/PRIMA/distances-OSM/ -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] [OSM-talk-fr] Réseau routier du Cantal : c'est fait
Ah bah oui, c'est a de lire trop vite, j'avais rat le lien en haut. :-[ Merci ! Le 28/06/2012 11:14, Nicolas Dumoulin a crit: Mais ils y sont :-) http://trac.clermont.cemagref.fr/svn/PRIMA/distances-OSM/ ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev] Modtile issue
Hi, On 06/27/2012 09:48 PM, yvecai wrote: AddTileConfig /osm_tiles2/ Default LoadTileConfigFile /etc/renderd.conf Try a lower-case D in default, and leave out the LoadTileConfigFile line altogether. (You would normally use either one AddTileConfig line for each style you have, or a single LoadTileConfig line.) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Modtile issue
Thanks Frederik, while your remarks make sense, it's not enough I'm afraid. Is there any way to log how mod_tile handles requests? apachectl -t -D DUMP_MODULES /usr/sbin/apachectl: line 87: ulimit: open files: cannot modify limit: Operation not permitted [Thu Jun 28 08:49:47 2012] [notice] Loading tile config default at /osm_tiles2/ for zooms 0 - 18 from tile directory /var/lib/mod_tile with extension .png and mime type image/png Loaded Modules: core_module (static) log_config_module (static) logio_module (static) mpm_prefork_module (static) http_module (static) so_module (static) alias_module (shared) auth_basic_module (shared) authn_file_module (shared) authz_default_module (shared) authz_groupfile_module (shared) authz_host_module (shared) authz_user_module (shared) autoindex_module (shared) cgi_module (shared) deflate_module (shared) dir_module (shared) env_module (shared) mime_module (shared) negotiation_module (shared) reqtimeout_module (shared) rewrite_module (shared) setenvif_module (shared) status_module (shared) tile_module (shared) Syntax OK 2012/6/28 Frederik Ramm frede...@remote.org Hi, On 06/27/2012 09:48 PM, yvecai wrote: AddTileConfig /osm_tiles2/ Default LoadTileConfigFile /etc/renderd.conf Try a lower-case D in default, and leave out the LoadTileConfigFile line altogether. (You would normally use either one AddTileConfig line for each style you have, or a single LoadTileConfig line.) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 __**_ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.**org/listinfo/devhttp://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Retina tiles - best way to support them?
Hi, FWIW, Maperitive provides a resolution parameter to its generate-tiles command. The parameter is an integer value indicating the scale to use when rendering tiles - the default 1 renders 256x256 tiles. If you set it to 2, you get 512x512. Technically the whole thing is implemented by scaling the graphics, which is quite easy to do in GDI+ (.NET graphics engine). The user doesn't have to change the map style. I used the same technique to achieve the subpixel accuracy in Maperitive (since GDI+ doesn't provide for this): http://braincrunch.tumblr.com/post/13459650973/maperitive-beta-subpixel-accuracy Best regards, Igor On Tue, Jun 26, 2012 at 11:05 PM, Frederik Ramm frede...@remote.org wrote: Hi, I have had some people asking whether I could supply them with Retina map tiles. Retina is an Apple brand name for higher resolution displays, and these users tend to mean tiles with twice the resolution. I wonder if anyone has done this already. I can think of a number of possible angles to attack this: 1. Double all font sizes, line widths, etc. in the Mapnik style file (recent Mapnik versions also have a built-in scaling option that achieves about the same) and adapt all scale denominators accordingly. This would mean that meta tile size, tile size, and everything else would remain unchanged but you'd be shifting everything by one zoom level - what was on one z16 tile before is now on four z17 tiles. The Retina user would see less detail on the same zoom level and therefore would have to go down to z19 to see what is currently shown on 18. Also, font nastiness along the metatile edges would increase; the amount of font nastiness depends on the ratio of tile size to font size, so doubling font sizes and keeping metatile sizes will increase label clipping and other strange things. (Simply increasing the buffer doesn't help.) 2. Modify style as per 1., but also double the size of meta tiles to 4096x4096. Cut 16x16 normal tiles out of one meta tile, rather than 8x8. This avoids the increase in font nastiness but requires internal processes to adapt to larger metatiles. The zoom level shift problem is the same as in 1. 3. Modify style as per 1., double size of meta tiles to 4096x4096, and double size of tiles to 512x512. This avoids the increase in font nastiness *and* it has the nice effect that one Retina tile at a certain zoom level shows exactly the same content as a normal tile, just on 512x512 instead of 256x256 and therefore at twice the resolution. It would, however, require clients (OpenLayers et al.) to work with the larger tile size. Your thoughts on these options - are there more than these three, perhaps? - would be most welcome. (Tiles for printing is a very similar issue - print users tend to want quad-resolution tiles, and again you have the options of shifting the zoom level by 2 or making 1024x1024 tiles.) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 __**_ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.**org/listinfo/devhttp://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osmosis + postgis 2.0 - usage of legacy function namens
Hi Brett postgis 2.0 is availiable - and making still some problems. ALL the old functions without st_ have gone and osmosis 0.40.1 is in little trouble. i.e. my diff-update is missing the good old Collect (and may be more). i can (and have to) install the postgis legacy.sql to get them back. But it would be better if that is not needed. http://postgis.refractions.net/docs/PostGIS_FAQ.html#legacy_faq Regards walter -- View this message in context: http://gis.19327.n5.nabble.com/osmosis-postgis-2-0-usage-of-legacy-function-namens-tp5234278p5713863.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Retina tiles - best way to support them?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 27-06-12 23:12, Robert Joop wrote: Why unreadable? What viewport setting do you use? A mapquest widget is used within a native app. angles I didn't saw you comment on was: going svg.gz all the way. Rendering tiles in SVG, doing so with a clue, for example fixed poit coordinates allows a decent compression over an easy zoom. How good is the SVG support on mobile devices? http://en.wikipedia.org/wiki/Scalable_Vector_Graphics#Mobile_profiles What about devices without decent SVG support? Serve legacy PNG available at fixed resolutions. Do you want to have two rendering pipelines, one SVG for higher pixel ratios and one PNG for less capable devices/browsers? Yes, don't break what ain't broken, and introduce a new better way that is slowly adopted. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk/sj9YACgkQYH1+F2Rqwn1g4gCghwBGrr/F843P8LO2gqOxaSqp vh8AnAk9t8VpC4pWuZ3vzaRemXuTCYWG =M6if -END PGP SIGNATURE- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
