length () in relations file
What about the length function for relations? I know this once was supported in the functions branch (or at least previous patches before the branch existed). Does such a function make sense: route=bicycle & ( distance>300 | length() > 300000 ) { apply .... } ?? Currently this puts out an (usable) error that length is not supported in relations file. Is this not implementable to to superrelations and their like? -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
On 04/02/13 10:11, Felix Hartmann wrote:
What about the length function for relations? I know this once was supported in the functions branch (or at least previous patches before the branch existed). Does such a function make sense: route=bicycle & ( distance>300 | length() > 300000 ) { apply .... }
There was a typo where it was checking if the function was supported for nodes instead of relations. Now fixed. ..Steve
Great! On 04.02.2013 21:52, Steve Ratcliffe wrote:
On 04/02/13 10:11, Felix Hartmann wrote:
What about the length function for relations? I know this once was supported in the functions branch (or at least previous patches before the branch existed). Does such a function make sense: route=bicycle & ( distance>300 | length() > 300000 ) { apply .... }
There was a typo where it was checking if the function was supported for nodes instead of relations. Now fixed.
..Steve
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
Can something like the length function also be implemented for polygons to render big lakes earlier? For example natural=water & area() > 10 [0x3c resolution 16] natural=water [0x3c resolution 18] (gmaptool shows this area in sq km)
There was a typo where it was checking if the function was supported for nodes instead of relations. Now fixed.
..Steve
-- keep on biking and discovering new trails
Felix openmtbmap.org & www.velomap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Minko, It might be possible. The problem to be solved is that the garmin map geometry is not rectangular. So at the moment I don't know how the area size of a polygon can be calculated in a metric unit. WanMil
Can something like the length function also be implemented for polygons to render big lakes earlier? For example natural=water & area() > 10 [0x3c resolution 16] natural=water [0x3c resolution 18]
(gmaptool shows this area in sq km)
There was a typo where it was checking if the function was supported for nodes instead of relations. Now fixed.
..Steve
-- keep on biking and discovering new trails
Felix openmtbmap.org & www.velomap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all,
- Doing something with values that are separated with ';'. >This is >> clearly desirable, but knowing what exactly to do is less >clear. >> I think it would have to be enabled on a tag-by-tag basis. > >I >had already been chewing this one over. If we are able to treat the >values as lists, where the normal case degenerates to a list of one >value, then we could think of simple list manipulation functions such as >"first element", "last element", "count of elements", "element N". In >practice the count of elements will be quite low (often 2-3 will be >enough I think), so allowing a reference to a non-existing element >(returning an empty string) would allow quite powerful style-file >constructions with only a couple of lines. I'm sure we can get by >without "for each element" constructions which sound more difficult to >implement. > >Nuts to crack: > > * how to handle a ";" in the data itself >(escape with preceding backslash? enclose value in quotes?) Really this >will need standardising across all editors/consumers, but I'm under no >illusions about the feasibility of that!
Yes, indeed, the array-handling could be the perfect overkill solution. What about thinking a more simple way? Wouldn't it be enough to treat a ';' like a 'continue' statement? Split the string, create a new object with the remaining string part, and continue rule testing from start. So, no map makers would have to care about this new option. I don't know about mkgmap's internals, could you imagine this is possible? Btw: there are tags where dividing could be a disadvantage, like in opening hours. So only certain keys would be good to split, e.g. amenity, or cuisine So mkgmap would really be the first application (at least I know...) to support ';' tagged objects. Cheerio Manfred PS: It was a pleasure for me you meet you in Essen, was a lot of fun and very interesting. Thank you all for coming, especially Steve and WanMil. This has given me some motivation to continue on my sleeping project
Hi Wanmil, Maybe it is easier to calculate the total lenght of the circumference of the polygon ways instead of the area? PS mkgmap-r2484 is rendering the borders ok now, thanks!
It might be possible. The problem to be solved is that the garmin map geometry is not rectangular. So at the moment I don't know how the area size of a polygon can be calculated in a metric unit.
WanMil
I'm experimenting a bit with the length() function in the polygons file, but the results are a bit unexpected. In my polygon style rule I have natural=water & length()>10000 [0x3e resolution 16] I would expect that mkgmap draws the whole relation of the Wolderwijd: http://www.openstreetmap.org/browse/relation/1204374 The total length of the relation is 33,79 km, see http://ra.osmsurround.org/analyzeRelation?relationId=1204374&_noCache=on The outer way is only one big way, http://www.openstreetmap.org/browse/way/80129565 But mkgmap draws only half of the lake, see length10km.jpg If I make natural=water & length()>5000 [0x3e resolution 16] it is a bit better, but still incomplete. Now this isnt a big issue, because I can use continue for higher zoomlevels, like natural=water & length()>10000 [0x3e resolution 16-17 continue] natural=water & length()>5000 [0x3e resolution 18-19 continue] etc Just wondering why the polygon isn't rendered completely (if I zoom in, the polygon is still the same edgy looking) Wanmil wrote:
It might be possible. The problem to be solved is that the garmin map geometry is not rectangular. So at the moment I don't know how the area size of a polygon can be calculated in a metric unit.
WanMil
Can something like the length function also be implemented for polygons to render big lakes earlier? For example natural=water & area() > 10 [0x3c resolution 16] natural=water [0x3c resolution 18]
(gmaptool shows this area in sq km)
Hi Minko, I assume the polygon is cut into smaller pieces because it has inner polygons. The length() function sees only the parts after cutting. Gerd Minko-2 wrote
I'm experimenting a bit with the length() function in the polygons file, but the results are a bit unexpected.
In my polygon style rule I have natural=water & length()>10000 [0x3e resolution 16]
I would expect that mkgmap draws the whole relation of the Wolderwijd: http://www.openstreetmap.org/browse/relation/1204374 The total length of the relation is 33,79 km, see http://ra.osmsurround.org/analyzeRelation?relationId=1204374&_noCache=on The outer way is only one big way, http://www.openstreetmap.org/browse/way/80129565
But mkgmap draws only half of the lake, see length10km.jpg If I make natural=water & length()>5000 [0x3e resolution 16] it is a bit better, but still incomplete.
Now this isnt a big issue, because I can use continue for higher zoomlevels, like natural=water & length()>10000 [0x3e resolution 16-17 continue] natural=water & length()>5000 [0x3e resolution 18-19 continue] etc
Just wondering why the polygon isn't rendered completely (if I zoom in, the polygon is still the same edgy looking)
Wanmil wrote:
It might be possible. The problem to be solved is that the garmin map geometry is not rectangular. So at the moment I don't know how the area size of a polygon can be calculated in a metric unit.
WanMil
Can something like the length function also be implemented for polygons to render big lakes earlier? For example natural=water & area() > 10 [0x3c resolution 16] natural=water [0x3c resolution 18]
(gmaptool shows this area in sq km)
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
lenght10km.jpg (72K) <http://gis.19327.n5.nabble.com/attachment/5749426/0/lenght10km.jpg>; length5km.jpg (71K) <http://gis.19327.n5.nabble.com/attachment/5749426/1/length5km.jpg>;
-- View this message in context: http://gis.19327.n5.nabble.com/length-in-relations-file-tp5747988p5749436.ht... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Minko, I think I found a formula to calculate the area size in a metric unit. But I have a problem to test that because I don't know the real area size of an OSM polygon. Can anybody please send some way (polygon) ids with it's real world area size? WanMil
Hi Minko,
It might be possible. The problem to be solved is that the garmin map geometry is not rectangular. So at the moment I don't know how the area size of a polygon can be calculated in a metric unit.
WanMil
Can something like the length function also be implemented for polygons to render big lakes earlier? For example natural=water & area() > 10 [0x3c resolution 16] natural=water [0x3c resolution 18]
(gmaptool shows this area in sq km)
There was a typo where it was checking if the function was supported for nodes instead of relations. Now fixed.
..Steve
-- keep on biking and discovering new trails
Felix openmtbmap.org & www.velomap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Wanmil, That would be great, can it calculate the size of a multipolygon as well (because a lake is often split up in multiple small sections). The area sizes of all polygons in a garmin img tile are visible with gpsmapedit, http://www.geopainting.com/
I think I found a formula to calculate the area size in a metric unit. But I have a problem to test that because I don't know the real area size of an OSM polygon.
Can anybody please send some way (polygon) ids with it's real world area size?
0> In article <51194252.7080409@web.de>, 0> WanMil <URL:mailto:wmgcnfg@web.de> ("Wanmil") wrote: Wanmil> It might be possible. The problem to be solved is that the Wanmil> garmin map geometry is not rectangular. So at the moment I Wanmil> don't know how the area size of a polygon can be calculated in Wanmil> a metric unit. I did this by preprocessing in C++, which adds a "computed:area" tag to each area (including multipolygons if TWOPASS is defined): I'm stuck with an old osmium that can't handle 64-bit ids, but it should still compile and operate with a more up-to-date version. I really ought to get around to writing this up for the OSM wiki...
participants (7)
-
Felix Hartmann -
GerdP -
Manfred Brenneisen -
Minko -
Steve Ratcliffe -
Toby Speight -
WanMil