Re: [OSM-dev-fr] carte interactive, Mali
Salut Pierre,
On peut peut-être demander de l'aide sur la liste dev-fr (en copie), ou
sinon sur dev (en anglais) ?
Merci d'avance les gars (et les filles, bien sûr) ! ;-)
Bien cordialement,
Jean-Guilhem
Le 13/04/2012 20:41, Pierre Béland a écrit :
Avant d'ajouter la fonction de Crowdsourcing, j'ai légèrement remanié
la carte interactive du Mali.
http://pierzen.dev.openstreetmap.org/hot/openlayers/mali.php
J'ai ajouté la section de droite qui servira à ajouter les
instructions. Maintenant la fonction de description des marqueurs
fonctionne correctement, tant pour les localités que les aéroports.
Et je vais maintenant greffer les instructions de Crowdsourcing.
Mais un problème auquel on devrait répondre, c'est l'encombrement des
icônes de marqueurs sur la carte. Pour l'instant, j'ai réduit la
taille des cercles représentant les localités.
Voici une brève description du problème. Pourrais-tu trouver quelqu'un
qui peut nous aider à résoudre ce problème?
J'utilise présentement le styleMap suivant :
var styleMap_villes2 = new OpenLayers.StyleMap({
default: new
OpenLayers.Style(OpenLayers.Util.applyDefaults({
graphicOpacity: 0.5,
pointRadius: 4}, OpenLayers.Feature.Vector.style[default]))
});
Pour diminuer l'encombrement, il serait bien d'avoir un styleMap avec
une fonction de variabilité de la taille selon le niveau de zoom. Aux
niveaux de zoom supérieur, il serait aussi possible de ne pas afficher
les marqueurs, laissant ainsi la place au texte de description des
localités.
J'ai vu l'exemple suivant où une fonction permet de modifier la
variable pointRadius. Mais ne réussit pas à le faire fonctionner. Il y
a un traitement en JQuery avec la variable ${radius}. Je ne suis
suffisamment familier avec le tout pour modifier et déboguer le tout.
var style_villes = new OpenLayers.Style({
pointRadius: *${radius}*,
fillColor: red,
fillOpacity: 0.8,
strokeColor: #ff,
strokeWidth: 2,
strokeOpacity: 0.8
}, {
context: {
*radius: function(feature)* {
return Math.min(feature.attributes.count, 7) + 3;
},
}
});
var styleMap_villes = new OpenLayers.StyleMap({
default: style_villes,
select: {
fillColor: #8aeeef,
strokeColor: #32a8a9
}
});
//
/Pierre/
//
--
gpg 0x5939EAE2
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
Re: [Potlatch-dev] [OpenStreetMap] #4354: Show direction of coastline and enclosed bodies of water
#4354: Show direction of coastline and enclosed bodies of water -+-- Reporter: stevage | Owner: potlatch-dev@… Type: enhancement | Status: new Priority: minor| Milestone: Component: potlatch2| Version: Keywords: | -+-- Comment(by Richard): Yes, I'd very much like to do that (perhaps by a graduated fill on one side). One way to do this would be by precalculating the offset arrays, as per Parallelise.as, for any style that requires them; then probably keeping them in WayUI. -- Ticket URL: https://trac.openstreetmap.org/ticket/4354#comment:1 OpenStreetMap http://www.openstreetmap.org/ OpenStreetMap is a free editable map of the whole world ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] [OpenStreetMap] #4354: Show direction of coastline and enclosed bodies of water
#4354: Show direction of coastline and enclosed bodies of water -+-- Reporter: stevage | Owner: potlatch-dev@… Type: enhancement | Status: new Priority: minor| Milestone: Component: potlatch2| Version: Keywords: | -+-- Comment(by sdoerr): How about a line that's blue on the seaward side and green or brown on the landward side? -- Ticket URL: https://trac.openstreetmap.org/ticket/4354#comment:2 OpenStreetMap http://www.openstreetmap.org/ OpenStreetMap is a free editable map of the whole world ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [OSM-dev] Yevaud SSD Drive
Thanks for this great response Kai, it's incredibly useful. John From: Ian Dees [mailto:ian.d...@gmail.com] Sent: 13 April 2012 03:05 To: Kai Krueger Cc: dev@openstreetmap.org Subject: Re: [OSM-dev] Yevaud SSD Drive This is a great writeup, Kai. I hope you throw it on the wiki or something. I'll throw in my 2 cents: The OSM US tile server has a worldwide osm2pgsql database set up for experimental rendering. It has almost no tile rendering load (because it's not really doing anything notable yet) and I had it updating every 2 hours before the diff location changed. It has four 600GB WD Velociraptor disks in a RAID10 set up and was usually able to catch up those 2 hours in 15-30 minutes. On Thu, Apr 12, 2012 at 8:39 PM, Kai Krueger kakrue...@gmail.com wrote: There are two main components to the storage system of a tile server, each of which can have different requirements depending on the circumstances 1) Tile storage cache For the tile storage usually one needs quite a bit of space, but performance isn't quite as critical. For a general purpose world wide map you will likely need somewhere on the order of above 600 GB. The full world wide tile set is considerably larger than that, but rendering on the fly of e.g. z18 ocean tiles is usually possible without too much problems. I don't know the exact scaling, but it seems like above somewhere between 300 - 600 GB the cache hit rate only increases slowly with size of the cache. Performance wise, it appears like 1000 tiles/s will generate somewhere on the order of 300 - 500 iops on the disk system, although that obviously depends on the size of ram of the server and the distribution of areas served. This is a level of performance that you can probably get out a raid array of a few sata disks. The performance requirement on this part of the disks likely scale fairly straightforward with the number of tiles served per second. Adding a reverse proxy in front of the tile server can also help reasonably to distribute load for tile serving. For most tile servers I have seen so far tile serving hasn't really been much of an issue, but in the order above 1000 Tiles/s you probably do need to consider it as well. 2) Rendering database The rendering database is where for most people the disk performance bottlenecks are. For the full planet, the postgis database with indexes is around 300 - 400GB in size. This is as others have pointed out where some people use SSDs for. Quite a bit of performance is consumed in keeping the database up to date with minutely diffs from OSM. This performance does not depend at all on how many tiles you serve, but only the rate of editing in OSM. From what I have seen (and other might correct me), a 2 - 4 disk sata raid array might not be able to keep up with edits during absolute peak editing times (e.g. Sunday afternoon European time), but should catch back up during the night. On top of that is the actual rendering of tiles. As typically one doesn't re-render tiles in advance (other than low zoom tiles), but only once they are actually viewed. Rendering performance does to some degree depend on the tile serving performance. If it doesn't matter how up to date rendered tiles are, rendering requests can be queued and rendered during quiet periods, which considerably reduces the performance requirements on the database. So overall whether you need an SSD for the database mostly depends on how up-to-date you want to me with respect to OSM edits. If you want to be in the order of minutes behind OSM, you probably will need an SSD. Given that a fast update is important for mappers as reward for their work, the SSD in osm's tile server has been a big win. If daily updates or less are fine, then you might not need one. Once you get down to monthly updates, you are likely best not using an updateable database but do full reimports, the size of the database reduces typically to less than half the size. It also depends on how spatially distributed your requests are. If e.g. your site has a bunch of locations around which it displays local maps. I.e. the same locations are shown over and over again, the rendering load is much less than if you offer Downloading country wide tiles for offline use in a mobile app even with the same amount of serving load. If you don't need a world wide map, then hardware requirements also considerably reduce and once you get down to only e.g. a country like e.g. Italy or the UK, you possibly don't really have to worry about the database anymore at all, as any modern hardware is probably sufficient. Kai On 04/12/2012 03:53 PM, Paul Norman wrote: I believe the SSD is used for the database. Before the SSD the DB was on the RAID10 array. I'm not sure four 300 GB 10k RPM drives are much cheaper than a SSD. You might find looking through munin for yevaud helpful - http://munin.openstreetmap.org/openstreetmap/yevaud.openstreetmap/#disk The SSD is sdd according to the wiki. How many
Re: [OSM-dev] Updating own tile server
On Thu, Apr 12, 2012 at 12:06 PM, Anwar Azulfa an...@troyans.net wrote: I fount http://www.hyperionreactor.net/blog/how … r-database Is your map server working now, If not then before running osmosis, That should be working. But when i execute ./osmosis --read-replication-interval-init workingDirectory=/mnt/changesets/ i got error messages like bellow : snip org.openstreetmap.osmosis.core.OsmosisRuntimeException: Task type read-replication-interval-init doesn't exist. Have you made changesets directory or edited that file according to you. Hope it will help. -- Parveen Arora www.parveenarora.in E-Mail: m...@parveenarora.in ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] Geofabrik downloads post-licence-change
From: Frederik Ramm [mailto:frede...@remote.org] Subject: Re: [OSM-talk] Geofabrik downloads post-licence-change Hi, On 04/13/12 10:45, Stefan Keller wrote: One question related to this I've always wanted to ask you, is: When I download the newest daily extract, like e.g. switzerland.osm.pbf (timestamp usually around 4:00 AM), and I look inside the db for the most recent added node, this node has a creation-date of around 7 PM of the day before (currently node 1711815745 7:10 PM). I blogged about this a while ago: http://blog.geofabrik.de/?p=75 The process has changed a little meanwhile but basically it's still the same procedure. Something I've wondered is if it is more efficient to be generating these with osmosis with a planet file updated daily or with a pgsnapshot database updated continually? ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] Geofabrik downloads post-licence-change
Hi, On 04/13/2012 11:25 AM, Paul Norman wrote: Something I've wondered is if it is more efficient to be generating these with osmosis with a planet file updated daily or with a pgsnapshot database updated continually? I have little experience with the pgsnapshot schema so cannot really say. When we started doing the Geofabrik extracts, that schema wasn't around and PostGIS was at release 1.3 and had really bad point-in-polygon performance so unless you were happy with rectangular extracts, it was impossible to run the job off a PostGIS database. Things might have changed now and I'd love to hear from someone who tried it. 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] [OSM-talk] Geofabrik downloads post-licence-change
Frederik Ramm wrote: Hi, On 04/13/2012 11:25 AM, Paul Norman wrote: Something I've wondered is if it is more efficient to be generating these with osmosis with a planet file updated daily or with a pgsnapshot database updated continually? I have little experience with the pgsnapshot schema so cannot really say. When we started doing the Geofabrik extracts, that schema wasn't around and PostGIS was at release 1.3 and had really bad point-in-polygon performance so unless you were happy with rectangular extracts, it was impossible to run the job off a PostGIS database. Things might have changed now and I'd love to hear from someone who tried it. Those who are interested in point-in-polygon performance should read this document which describes how to use a clever trick instead of raw power. http://www.gaia-gis.it/spatialite-3.0.0-BETA1/WorldBorders.pdf I had a try and splitted the most accurate Finnish municipality polygons into a chessboard like polygons and it really makes difference with PostGIS too. Recent OpenJUMP Plus version has all the tools which are needed: Create Grid tool for making the splitting layer and Polygon Overlay for cutting the original complicated polygon layer into pieces by the splitting layer. -Jukka Rahkonen- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Exhaustion of 32bit signed integer range expected this year
Hi, this is just a reminder that our current highest node ID is about 1.7 billion, and that it grows by about 0.05 billion every month. This means that it is likely that by the end of 2012, we will have reached (or be very close to reaching) the end of the 32bit signed integer range (2.15 billion, or 2^31-1). See also: http://tools.geofabrik.de/munin/osm_nodes-year.png Software processing OSM data will need to either use unsigned integers (which can be problematic in cases where negative values are also required), or switch to 64bit integers altogether. This is also relevant when dealing with database tables; depending on what schema you are using, you might have 32bit signed IDs there as well. osm2pgsql can be compiled with 64bit ID support but that is not enabled in the standard binary distributions. If you are in any way involved with writing software for OSM, it may be worth thinking about that now. 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: [Potlatch-dev] [OpenStreetMap] #4354: Show direction of coastline and enclosed bodies of water
#4354: Show direction of coastline and enclosed bodies of water -+-- Reporter: stevage | Owner: potlatch-dev@… Type: enhancement | Status: new Priority: minor| Milestone: Component: potlatch2| Version: Keywords: | -+-- Comment(by stevage): Richard, I was just thinking of something like an arrow head with just one side. (That is, --,--,--, rather than --) I can't remember if Halcyon/MapCSS supports anything like that (I guess not). Are you thinking that would be too slow to render, compared to a fill? -- Ticket URL: https://trac.openstreetmap.org/ticket/4354#comment:3 OpenStreetMap http://www.openstreetmap.org/ OpenStreetMap is a free editable map of the whole world ___ Potlatch-dev mailing list potlatch-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [OSM-dev] Exhaustion of 32bit signed integer range expected this year
Frederik Ramm frede...@remote.org wrote: Software processing OSM data will need to either use unsigned integers (which can be problematic in cases where negative values are also required), or switch to 64bit integers altogether. Or used for other purposes like in osm2pgsql. Will the upcoming licence change add a delay to this problem? Sven -- We just typed make (Stephen Lambrigh, Director of Server Product Marketing at Informix about porting their Database to Linux) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Exhaustion of 32bit signed integer range expected this year
Hi, On 04/13/2012 04:30 PM, Sven Geggus wrote: Or used for other purposes like in osm2pgsql. Will the upcoming licence change add a delay to this problem? No; if anything, node IDs will be used up faster because if the something is deleted by the bot and later re-created with a new ID then that would count extra. However, even if *all* problematic nodes were deleted and re-created, that would be less edit activity than we normally see in one month, so it wouldn't have a big impact on the outcome. 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] Exhaustion of 32bit signed integer range expected this year
RSN a large number of sites using OSM data will be reloading their databases, due to a certain well known change :-). It seems as if it would really make sense to make the 64bit ID version of osm2pgsql the default now and communicate that it might be a good idea to switch on the upcoming reload. Do we have any idea what the actual impact on DB size etc is? Simon PS: CC'd to the CWG for good form. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Exhaustion of 32bit signed integer range expected this year
On 13/04/2012 15:15, Frederik Ramm wrote: This means that it is likely that by the end of 2012, we will have reached (or be very close to reaching) the end of the 32bit signed integer range (2.15 billion, or 2^31-1). Thanks for the reminder. I was a bit worried about this having coded a lot of stuff in PHP. I now realise that so long as it is running on 64-bit hardware, PHP uses 64-bit ints, But is is an issue for people running PHP utilities on 32-bit hardware, who would have to either move or treat the IDs as strings. David ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Exhaustion of 32bit signed integer range expected this year
The latest Windows build of osm2pgsql is just over two years old now. Perhaps we will reach a new build by the end of this year. -Jukka Rahkonen- Frederik Ramm wrote: Hi, this is just a reminder that our current highest node ID is about 1.7 billion, and that it grows by about 0.05 billion every month. This means that it is likely that by the end of 2012, we will have reached (or be very close to reaching) the end of the 32bit signed integer range (2.15 billion, or 2^31-1). See also: http://tools.geofabrik.de/munin/osm_nodes-year.png Software processing OSM data will need to either use unsigned integers (which can be problematic in cases where negative values are also required), or switch to 64bit integers altogether. This is also relevant when dealing with database tables; depending on what schema you are using, you might have 32bit signed IDs there as well. osm2pgsql can be compiled with 64bit ID support but that is not enabled in the standard binary distributions. If you are in any way involved with writing software for OSM, it may be worth thinking about that now. 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 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Exhaustion of 32bit signed integer range expected this year
On Fri, 13 Apr 2012, David Earl wrote: On 13/04/2012 15:15, Frederik Ramm wrote: This means that it is likely that by the end of 2012, we will have reached (or be very close to reaching) the end of the 32bit signed integer range (2.15 billion, or 2^31-1). Thanks for the reminder. I was a bit worried about this having coded a lot of stuff in PHP. I now realise that so long as it is running on 64-bit hardware, PHP uses 64-bit ints, But is is an issue for people running PHP utilities on 32-bit hardware, who would have to either move or treat the IDs as strings. Unless you're using PHP on Windows, where even in a 64-bit build on 64-bit hardware, the integer size is only a signed 32-bit integer. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] Geofabrik downloads post-licence-change
From: Frederik Ramm [mailto:frede...@remote.org] Subject: Re: [OSM-talk] Geofabrik downloads post-licence-change Hi, On 04/13/2012 11:25 AM, Paul Norman wrote: Something I've wondered is if it is more efficient to be generating these with osmosis with a planet file updated daily or with a pgsnapshot database updated continually? I have little experience with the pgsnapshot schema so cannot really say. When we started doing the Geofabrik extracts, that schema wasn't around and PostGIS was at release 1.3 and had really bad point-in- polygon performance so unless you were happy with rectangular extracts, it was impossible to run the job off a PostGIS database. Things might have changed now and I'd love to hear from someone who tried it. Unfortunately there is no --dataset-bounding-polygon task so I couldn't do it with osmosis. I tried the UK with jxapi which does support polygons and it errored after about 80 minutes. Just for reference, a typical way[natural=coastline] query generates 5G of data and takes just over an hour on my hardware. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Why 5174 ?
On Thu, 12 Apr 2012, colliar wrote: Please update tested to at least r5178 (i18 - update) No use in doing so, as except for hu language the update does not really improve situation, as all new strings are missing. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] no latest built this morning
On 11/04/12 09:56, Dirk Stöcker wrote: Hi Dirk probably tomorrow the old JOSM server will be turned down and move to its new destination. Expect small downtimes (maybe 30 minutes). The installation on the new server seems to be stable, but very likely I will have overlooked something, so afterwards please report any errors which you notice. There was no latest built this morning. Cheers Colliar signature.asc Description: OpenPGP digital signature ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
