Re: [OSM-dev-fr] OSM API 0.6 = PBF
Le samedi 25 décembre 2010, à 19:29:42 +0100, rldhont a écrit : J'ai réussi à exploiter ce format en Python, pour lequel aucun code n'était disponible. Ma conclusion est que ce format est plus léger en terme de taille mais aussi de traitement et d'analyse des données. J'ai voulu faire l'essai pour mon projet de rivières et fleuves: http://renevier.net/maps/rivers/ C'est en python aussi. Je me suis basé sur le parseur disponible ici: http://code.google.com/p/pyosm/source/browse/src/parsers_pbf.py Or, l'extraction des données est plus lente avec cette technique qu'un parseur maison basé sur sax. Par exemple, pour juste l'extraction des données sur l'ensemble de l'ile de france, il faut 11 minutes avec un fichier xml décompressé (+1grosse minute pour décompresser), et 15 minutes pour un fichier pbf. J'ai observé sur les autres tests que j'ai effectué le même ordre de grandeur de différence. a+ arno ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev] Layered Tiling (Mapnik)
Sounds great, but it's not that easy, I think... Depending of the map layers you compose, you would need different text layer compositions. For example: In my public transport map, there are priorities for the texts; the name of a railway station has always a higher priority than the name of a bus stop. Hence, if there is bus stop nearby a railway station, the name of the bus stop is not displayed. Now, if you would decide to have different layers for railways and buses, and to switch off the railway layer, the name of the bus stop would have to reappear. To go one step further: Ideal would it be to move the colliding texts slightly instead of omitting them. But then, how to deal with different map layers? Markus Original-Nachricht Datum: Tue, 28 Dec 2010 07:30:51 +0100 Von: Igor Brejc igor.br...@gmail.com An: mar...@gmx.eu CC: Frederik Ramm frede...@remote.org, dev@openstreetmap.org Betreff: Re: [OSM-dev] Layered Tiling (Mapnik) On Mon, Dec 27, 2010 at 11:29 PM, mar...@gmx.eu wrote: But there is one problem you would have to deal with: there is no collision avoidance between the texts of different tile layers. That could be solved if the all the layers were rendered as a single map, but painted onto several layer bitmaps. I'm planning to implement something like this in Maperitive. Igor ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Layered Tiling (Mapnik)
You're right, that would be a problem. But I guess as long as you have raster-only data, there isn't a perfect way to solve this problem. An alternative would be to render text (and icons, since they can collide, too) on the client-side using JavaScript on top of server-generated tiles. The server could still perform the actual text placement and then send the text, text vectors and classes (=priorities) to the client which would then render it. Client would be able to determine that the bus stop label can be rendered if the railway station class is turned off, for example. In advanced scenario the client would even be able to do additional text placement automation, if necessary. Igor On Tue, Dec 28, 2010 at 11:10 AM, mar...@gmx.eu wrote: Sounds great, but it's not that easy, I think... Depending of the map layers you compose, you would need different text layer compositions. For example: In my public transport map, there are priorities for the texts; the name of a railway station has always a higher priority than the name of a bus stop. Hence, if there is bus stop nearby a railway station, the name of the bus stop is not displayed. Now, if you would decide to have different layers for railways and buses, and to switch off the railway layer, the name of the bus stop would have to reappear. To go one step further: Ideal would it be to move the colliding texts slightly instead of omitting them. But then, how to deal with different map layers? Markus Original-Nachricht Datum: Tue, 28 Dec 2010 07:30:51 +0100 Von: Igor Brejc igor.br...@gmail.com An: mar...@gmx.eu CC: Frederik Ramm frede...@remote.org, dev@openstreetmap.org Betreff: Re: [OSM-dev] Layered Tiling (Mapnik) On Mon, Dec 27, 2010 at 11:29 PM, mar...@gmx.eu wrote: But there is one problem you would have to deal with: there is no collision avoidance between the texts of different tile layers. That could be solved if the all the layers were rendered as a single map, but painted onto several layer bitmaps. I'm planning to implement something like this in Maperitive. Igor ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Layered Tiling (Mapnik)
Yes, would be a very good solution! The client would get the texts and their font information including their position and display them on its own. This could be done in Javascript. Even collision management would be possible (omitting texts which low priorities or moving them a bit). Of course, we would have to provide this priority information too. Alternatively, every text could be served as a bitmap instead of UTF-8 etc. In this case, the client wouldn't have to do any rendering. I think, I would prefer this solution. Maybe we should think about supplying abbreviations for the texts. So, the client could determine how much space is left and use either the full text or the abbreviated one. But I think, this needs not to be implemented in a first step, it should be a future expansion. ;-) Markus Original-Nachricht Datum: Tue, 28 Dec 2010 12:46:37 +0100 Von: Igor Brejc igor.br...@gmail.com An: mar...@gmx.eu CC: dev@openstreetmap.org Betreff: Re: [OSM-dev] Layered Tiling (Mapnik) You're right, that would be a problem. But I guess as long as you have raster-only data, there isn't a perfect way to solve this problem. An alternative would be to render text (and icons, since they can collide, too) on the client-side using JavaScript on top of server-generated tiles. The server could still perform the actual text placement and then send the text, text vectors and classes (=priorities) to the client which would then render it. Client would be able to determine that the bus stop label can be rendered if the railway station class is turned off, for example. In advanced scenario the client would even be able to do additional text placement automation, if necessary. Igor On Tue, Dec 28, 2010 at 11:10 AM, mar...@gmx.eu wrote: Sounds great, but it's not that easy, I think... Depending of the map layers you compose, you would need different text layer compositions. For example: In my public transport map, there are priorities for the texts; the name of a railway station has always a higher priority than the name of a bus stop. Hence, if there is bus stop nearby a railway station, the name of the bus stop is not displayed. Now, if you would decide to have different layers for railways and buses, and to switch off the railway layer, the name of the bus stop would have to reappear. To go one step further: Ideal would it be to move the colliding texts slightly instead of omitting them. But then, how to deal with different map layers? Markus Original-Nachricht Datum: Tue, 28 Dec 2010 07:30:51 +0100 Von: Igor Brejc igor.br...@gmail.com An: mar...@gmx.eu CC: Frederik Ramm frede...@remote.org, dev@openstreetmap.org Betreff: Re: [OSM-dev] Layered Tiling (Mapnik) On Mon, Dec 27, 2010 at 11:29 PM, mar...@gmx.eu wrote: But there is one problem you would have to deal with: there is no collision avoidance between the texts of different tile layers. That could be solved if the all the layers were rendered as a single map, but painted onto several layer bitmaps. I'm planning to implement something like this in Maperitive. Igor ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [Potlatch-dev] How about another build?
Ok, done. Btw, I notice a lot of pairs of features like this: feature name=Slipway line/ ... /feature feature name=Slipway point / ... /feature I guess the goal here is to have different icons for nodes vs areas? If so, would it be a better idea to allow something like: feature name=Slipway icon point=yes image=features/pois/boat-launch-24.png/ icon line=yes image=features/waterway__slipway.png / point / line / ... /feature Just checking before I implement this* and then find out there was another reason that I missed. Also, what is the thinking around the text part of the icon element? It seems a bit under-developed. Perhaps a more explicit description element which explains what the entity represents (eg, text from the wiki), and a title or something which uses string substitution to summarise the entity? Steve * Not a promise. On Sun, Dec 26, 2010 at 11:19 AM, Steve Bennett stevag...@gmail.com wrote: On Fri, Dec 24, 2010 at 9:15 PM, Richard Fairhurst rich...@systemed.net wrote: Have you had any thoughts about supplying icons for the new amenities? I don't think we can make something live with rows upon rows of ? ? ? ? ? ? ? ? ? ?. (Brian's SJJB set is usually the best place to look.) As you can see from my terrible power=* icons, graphic design is not really my strength :) Perhaps we could consider getting a more attractive default icon? Will have a look at SJJB though. Steve ___ Potlatch-dev mailing list potlatch-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
[OSM-dev] mod_tile - meta tile computation
Hi, I'm trying to write a nginx module which does more or less the same like mod_tile. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] mod_tile - meta tile computation
Sorry for the first, stupid mail.
I'm trying to write a nginx module which does more or less the same like
mod_tile. I reviewed a lot of the code but now I have a little problem
with the computation of paths to meta tiles. Could someone please
explain me how mod_tile creates file paths from a request and how the
offset is computed? My own code looks exactly the same but returns
x=0,z=0 for every input. I'm highly confused :)
The original code should look like this:
int xyz_to_meta(char *path, size_t len, const char *tile_dir, const char
*xmlconfig, int x, int y, int z)
{
unsigned char i, hash[5], offset, mask;
// Each meta tile winds up in its own file, with several in each leaf
directory
// the .meta tile name is beasd on the sub-tile at (0,0)
mask = METATILE - 1;
offset = (x mask) * METATILE + (y mask);
x = ~mask;
y = ~mask;
for (i=0; i5; i++) {
hash[i] = ((x 0x0f) 4) | (y 0x0f);
x = 4;
y = 4;
}
#ifdef DIRECTORY_HASH
snprintf(path, len, %s/%s/%d/%u/%u/%u/%u/%u.meta, tile_dir, xmlconfig, z,
hash[4], hash[3], hash[2], hash[1], hash[0]);
#else
snprintf(path, len, %s/%s/%d/%u/%u.meta, tile_dir, xmlconfig, z, x, y);
#endif
return offset;
}
#endif
The nginx code looks like this:
#define METATILE (8)
static ngx_int_t
ngx_http_serve_request_handler(ngx_http_request_t *r, struct protocol *cmd)
{
char*path;
unsigned char hash[5],offset,
mask;
int i,x,y;
ngx_http_core_loc_conf_t*clcf;
clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module);
if((path = ngx_palloc(r-pool, 256)) == NULL)
return NGX_HTTP_INTERNAL_SERVER_ERROR;
printf(original: %d, %d, %d\n, cmd-z, cmd-x, cmd-y);
x = cmd-x;
y = cmd-y;
//build meta file name
mask = METATILE - 1;
offset = (x mask) * METATILE + (y mask);
x = ~mask;
y = ~mask;
for(i=0; i5;i++) {
hash[i] = ((x 0x0f) 4) | (y 0x0f);
x =4;
y =4;
}
printf(%d,%u,%u\n,cmd-z,x,y);
return NGX_OK;
}
Thanks for any help.
best regards
philipp
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] mod_tile - meta tile computation
Hi, Philipp Borgers wrote: I'm trying to write a nginx module which does more or less the same like mod_tile. I reviewed a lot of the code but now I have a little problem with the computation of paths to meta tiles. Could someone please explain me how mod_tile creates file paths from a request and how the offset is computed? My own code looks exactly the same but returns x=0,z=0 for every input. I'm highly confused :) The result of this computation is a series of 5 integers stored in the hash[] array, plus an offset. The resulting x and y values are of no concern. The reason you are confused is proably because you have your code print out printf(%d,%u,%u\n,cmd-z,x,y); at the end, which is not what this code is supposed to compute. 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] mod_tile - meta tile computation
On 28.12.2010 21:04, Philipp Borgers wrote: I'm trying to write a nginx module which does more or less the same like mod_tile. I reviewed a lot of the code but now I have a little problem with the computation of paths to meta tiles. Not sure I understand what you need. Does this help? http://wiki.openstreetmap.org/wiki/User:Stephankn/knowledgebase#calculating_metatile_path Stephan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] mod_tile - meta tile computation
Am Dienstag, den 28.12.2010, 21:43 +0100 schrieb Frederik Ramm: The result of this computation is a series of 5 integers stored in the hash[] array, plus an offset. The resulting x and y values are of no concern. The reason you are confused is proably because you have your code print out printf(%d,%u,%u\n,cmd-z,x,y); at the end, which is not what this code is supposed to compute. What if we disable directory hashing but use meta tiling? Is this use case intended? snprintf(path, len, %s/%s/%d/%u/%u.meta, tile_dir, xmlconfig, z, x, y); In this use case x,y are of concern for snprintf but I don't understand the computation. We do a bitwise and with x and ~mask and then shift them 5 times 4 bits to the right. Which leads to strange values at least in my head. In theory the computation should map METATILE * METATILE tiles to one meta file? Which should result for x in [0,7] and y in [0,7] in the new values z/0/0.meta and for x in[8,15] and y in [8,15] in the values z/1/1.meta and so on. I should try to divide the input by METATILE if I'm right. Is there a detailed description of the meta file layout? Perhaps I don't see the obvious. Thanks for your help. regards philipp ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] mod_tile - meta tile computation
Hi,
Philipp Borgers wrote:
What if we disable directory hashing but use meta tiling? Is this use
case intended?
Everybody uses meta tiles nowadays. This means that the last item of the
hash quintuplet is somewhat degraded in that it only has one of the four
values 0x00, 0x08, 0x80, 0x88 - whereas without metatiles you would see
all 256 possible combinations there.
In theory the computation should map METATILE * METATILE tiles to one
meta file? Which should result for x in [0,7] and y in [0,7] in the new
values z/0/0.meta and for x in[8,15] and y in [8,15] in the values
z/1/1.meta and so on. I should try to divide the input by METATILE if
I'm right.
Now you've lost me. What this computation basically does is, it takes a
20-bit x value and a 20-bit y value (the coordinates of the tile):
(for 40 bits altogehter) and morphs that into a series of five 8-bit
values (again 40 bits), intermingling components of x and y:
This computation, and the resulting file names, are the same for
metatile and non-metatile mode, except that in single tile mode, the
file name of the tile is
////.png
(of course with the replaced by matching integer numbers 0-255)
whereas in metatile mode, the file name of the metatile is
////x000y000.meta
and the three least significant bits of x and y make up the offset
inside the metatile.
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
[josm-dev] new tested version?
Hi, what about a new tested version this year? Most problems related to plugin integration should be solved and imagery seems to be stable. We could target the 30.-31. Dec. nightly build as release candidate. Sebastian ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Patch for ticket #5760
2010/12/27 Rolf Bode-Meyer rob...@gmail.com: could please someone have a look at ticket #5760 and apply the patch or give some feedback if it's not ok? Oh, done. Thank you very much Sebastian. Rolf ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
