Re: [mkgmap-dev] TYP files and oruxmaps
On Tue, Aug 22, 2017 at 07:32:18AM +, Gerd Petermann wrote: sorry, no idea. The project oruxmaps seems to be closed source and unmaintained (last release is from Nov 2013). It is closed source, but I would not claim that it is unmaintained. Curiously, the "downloads" page is not listing the Android releases. According to http://www.oruxmaps.com/cs/en/more/history the most recent release is 7.0.4 from March 2017. Besides that I think it is not a good idea to use a rather outaged and undocumented format like the old Garmin img format for a new platform like Android. I agree. That said, Oruxmaps can be a reasonable option on an older Android device where the open-source OsmAnd would constantly crash due to running out of RAM. OruxMaps supports also many sensors, such as bicycle cadence sensor and heart rate sensor. I have some experience from OruxMaps 6.x with Brouter and MapsForge maps. (Because MapsForge uses the SD card for caching bitmaps of rendered vector map tiles, it is less memory-hungry than OsmAnd, which does not implement such caching.) If only there was an OSM-based open-source Android solution that would support address search, good-quality routing (with live recalculation) and recording of sensor data, all well integrated into a single program. Maybe OsmAnd could evolve to something like that if you accept that it would not necessarily run on a device with less than 2MiB RAM. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] new option shutdown_pc ?
On Sun, Apr 02, 2017 at 09:47:18AM +0200, Thomas Morgenstern wrote: maybee it is a good feature, to have the ability to shutdown the computer, after splitter and/or mkgmap is ready . But only , if splitter/mkgmap not ended with a error. I will read the error. This would seem to be better done by a script that invokes splitter and mkgmap. All that splitter and mkgmap would need to do is to follow the convention, that is, finish with exit status 0 when everything succeeds, and with a nonzero exit status in case of an error. Then, the script (or makefile or whatever) would implement the logic. Maybe sample scripts could be provided for both POSIX-like systems and for Microsoft Windows. I do not know about the shells that are available on Microsoft Windows (cmd.exe, PowerShell and whatnot), but on POSIX, something like the following should work, assuming that splitter and mkgmap follow the convention on exit codes: #!/bin/sh set -e # the above causes the script to abort on error wget ... java -jar splitter.jar ... java -jar mkgmap.jar ... # optional step: upload the map files to somewhere sudo shutdown now Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Copyright & License file reader improvements
On Tue, Dec 27, 2016 at 06:07:11PM -, Mike Baggaley wrote: Hi Gerd, please find attached a small patch that improves the loading of copyright and license data when the --copyright-file and --license-file options are used. It will attempt to load the data using ANSI, UTF-8, UTF-16 and the default code page. If it fails, more information is provided as to the reason why. I am not Gerd, and I am not that active with mkgmap any more, but I have some interest in character encodings. I had a quick look at the patch. It first tries ASCII (which is a proper subset of UTF-8), then UTF-8, UTF-16 and the default code page. I do not think that there is any need to try ASCII separately. Any valid ASCII input is also valid UTF-8. If the input is not valid UTF-8, things get tricky. I am not sure if UTF-16 is a good thing to try. Here is an example where 6 ASCII characters (which could be part of a non-ASCII, non-UTF-8 input) get misinterpreted as 3 Chinese glyphs in UTF-16: $ echo -n foobar|recode utf16..utf8;echo 景潢慲 Because of this, I would omit the UTF-16 pass altogether. If UTF-16 input is truly needed, the default code page could be set to it. Also, some non-UTF-8 superset of ASCII could accidentally look like valid UTF-8. For example, the bytes 0xc2 0xa0 could represent the two-character string U+00C2 U+00A0 in ISO 8859-1. But the same bytes could also be interpreted as the single UTF-8 encoded character U+00A0. I think that if multiple input formats are supported (which would be against the Unix philosophy of keeping programs simple), the selection must be explicit, by some command line switch that chooses to use the default code page instead of UTF-8. In my opinion, the current code is good as it is. Because mkgmap already deals with mostly UTF-8 input (the OSM data), I think it is consistent to assume that all text files are encoded in UTF-8. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Has anyone added a USA TIMEZONE overlay ontop of their custom maps?
On Tue, Jun 07, 2016 at 09:36:37PM -0400, greg crago wrote: I do not know how to add adminstrative boundaries or relations, but it would be nice if these were added to the USA. INDIANA is divided between cities and county boarders. I was just hoping someone had done this and I would like to add this info to my maps. Indiana http://www.openstreetmap.org/relation/161816 does not have a timezone=* yet. Maybe someone who is familiar with JOSM and the timezones could do this? Because I do not live in the US, I am reluctant to change the data myself. But I guess I could do it if nobody else steps up, and if you can provide me with a comprehensive list of states (counties, cities) and timezones. You see, I would want this data to be present in OSM, to benefit also other users than those using mkgmap-generated maps. If we have the data in OSM and if mkgmap starts to interpret it, then you would get the timezone borders "out of the box". I do not think that timezone borders would add any significant clutter to the map, so IMO they should be included in the default style. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Has anyone added a USA TIMEZONE overlay ontop of their custom maps?
On Tue, Jun 07, 2016 at 12:18:21PM +0300, Marko Mäkelä wrote: http://wiki.openstreetmap.org/wiki/Key:timezone seems to agree with my reasoning above. It also refers to a changeset that introduced time zones for the Australian states. However, all those modified objects have since then been removed, and the new Australian state relations do not seem to include timezone=*. Sorry, I was looking at a way, not at relations. At least http://www.openstreetmap.org/relation/2316595 (name=Queensland) is tagged with timezone=Australia/Brisbane. There is also an algorithmic problem of extracting boundaries of tagged areas. Even if all the administrative areas are tagged with timezone=*, we would want to derive the boundaries, so that only those administrative boundaries that also represent a time zone boundary (with different values on each side) will be displayed. Maybe the mkgmap bounds.zip could be extended with this information? Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Has anyone added a USA TIMEZONE overlay ontop of their custom maps?
On Mon, Jun 06, 2016 at 01:09:34PM -0400, greg crago wrote: Since I cannot seem to get this feature added to the OSM database (because it is not verifiable, or something) has anyone got this data from a different source and combined to maps together so I can tell when riding across the counrty thay I am crossing a timezone?? I would expect time zone to be an (explicit or implicit) attribute of a boundary=administrative relation. That is, the whole country or state (or province or city) would use the same time zone. If the above does not apply (for example, if some US state is being divided by a time zone boundary), then some overlay of an external data source would indeed seem to be needed. http://wiki.openstreetmap.org/wiki/Key:timezone seems to agree with my reasoning above. It also refers to a changeset that introduced time zones for the Australian states. However, all those modified objects have since then been removed, and the new Australian state relations do not seem to include timezone=*. http://taginfo.openstreetmap.org/keys/timezone lists a number of values starting with America/*. Maybe the US states are already tagged? There is also an algorithmic problem of extracting boundaries of tagged areas. Even if all the administrative areas are tagged with timezone=*, we would want to derive the boundaries, so that only those administrative boundaries that also represent a time zone boundary (with different values on each side) will be displayed. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] OT: Edge 705 firmware hacking
Hi Roger, On Wed, Jun 01, 2016 at 08:09:45AM -0400, Roger Stevenson wrote: I have been having issues with my Garmin Edge 705 seeing the map SD card and was hoping i could get copied of on older GCD file. In the time frame when I had the 705, I do not remember experiencing that kind of trouble. Maybe once or twice the map would just disappear suddenly. There were clear bugs in the conversion of recorded traces from the hidden internal format to the FAT file system in the internal memory. The bugs would slightly change between firmware updates, but never get fixed. I’ve been reading that downgrading then upgrading might take care of issue with the 705. If the issue is some corruption of an internal database, maybe a factory reset (hold Mode while powering up) would help? I remember that the list of recently searched places would appear corrupted whenever the map was updated. Maybe it will get too corrupted if the gmapsupp.img is updated sufficiently many times? If the issue is dirt, have you tried taking apart the Edge 705 to clean the contacts of the card slot? You should only need a Torx screwdriver. If I remember correctly, there is something attached with a cable to the back cover. Maybe it was the battery or the SD card slot. No soldering should be needed. Would it be possible to get the file 3468836 Edge605_705_310.gcd from you? I still have the files, but I cannot guarantee that they did not get spontaneously corrupted, because I did not store any checksums separately. I have expericenced spontaneous corruption a few times for photos that had not been accessed for years. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Satnav for non-proprietary maps?
On Sun, Feb 14, 2016 at 02:47:40PM -0500, Mark Bradley wrote: The other day I got to thinking-is there no such thing as a GPS/satnav that can display maps created in an open-source format, such as .pbf? First of all, navigation requires several features: * Map display * Routing graph information * Address index The first part is in my experience best done by maintaining a cache of map tiles in bitmap format on a MicroSD card. If you are moving in a "new" area for which your device is displaying map tiles for the first time, then it will take some time to fetch the vector data and render it into a bitmap. Typically, the device would quickly fetch and display already rendered tiles from the cache. The Mapsforge library works in this way. To my knowledge, Mapsforge supports neither routing nor address search. For those you would need a different type of index. I am not aware of any really good open source offline navigation application for Android. There is OsmAnd, but it consumes a lot of memory, because it does not maintain a cache of map tiles. It is not good at calculating routes, especially for bicycling. It can be interfaced with an external offline router http://brouter.de/ which uses its own file format. Brouter can also be interfaced with the closed-source applications Locus Map and OruxMaps. Both of them are using MapsForge for displaying the maps. As far as I understand, OruxMaps does not support offline address search. I have not tried Locus Map, but OruxMaps seems useable on a low-end device, hardly ever crashing due to running out of memory. It stores tracks and sensor data in SQLite tables on the MicroSD card. Perhaps an analogy would be an unlocked cellphone-you pay extra for it (or hack it), in exchange for additional flexibility. I wonder if there would be a market for such a thing. http://linuxg.net/osmscout-is-an-offline-navigation-app-for-ubuntu-touch/ For me, Ubuntu Phone is interesting, but not enough to warrant a purchase. I hope that there will some day be devices that are based on a system-on-chip that is supported by the mainline Linux kernel. With both Android and Ubuntu, my understanding is that upgrading the kernel is practically impossible, because some drivers are tied to a specific kernel version. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Slash character in name
On Tue, Dec 22, 2015 at 02:34:57PM +, Brian Egge wrote:
For destinations or names with more than one line, it's common to have
each line separated by a forward slash. I've tried to customize my map
to replace semicolon with slash, but the slash does not appear. Is the
slash an allowed character in a name or destination? I'm using the
Latin1 character set.
It should be allowed at least in names. A long time ago, I added a rule
to the default style that applies the names from type=boundary relations
to the lines, and I used the slash as a separator. It worked on my
Garmin Edge 705.
I think that the rule was effectively removed later, by the special
processing of boundaries. The rule is still there (or was as of r3643),
in the file resources/styles/default/relations, but probably
unreachable. I no longer have any Garmin device, so I cannot reliably
test this.
BTW, note that ${attribute} and $(member_attribute) refer to different
objects in the apply rules. I implemented the logic for
$(member_attribute), so that you could write such rules in the first
place. The $() syntax refers to the attributes of relation members,
while ${} refers to the attributes of the relation on which the apply is
being executed.
Best regards,
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Hiding long tunnels from map view while keeping them routable
On Tue, Oct 20, 2015 at 12:03:52AM -0700, GerdP wrote: Esp. the tags which express a planned (or not yet planned) status are problematic, they may be non-existent bridges or tunnels. Speaking of tunnels, would it be technically possible to hide tunnels from the map view, while keeping them in the routing graph? This could be useful in urban areas. A few years ago, I added rules to hide unrouteable tunnels, such as highway=service,access=private, or railway tunnels (subways). A separate discussion is whether it is practically feasible to hide such tunnels from the map display in the default style. In my opinion, it would be. As long as the tunnel exists in the routing graph, it can be used for routing (typically, for cars only). Pedestrians and bicyclists or anyone who is at the street level would not be confused by seeing the map cluttered with the "bogus" road. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style: highway=path means unpaved?
Hi Steve,
On Tue, Sep 08, 2015 at 06:34:34PM +1000, Steve Sgalowski wrote:
yet in brisbane , to ipswich area , most are paved with concrete , or
bitumen
some bicycles just use the main road ..
So how can you code for that ?
If the ways are accurately tagged as surface=paved or surface=concrete
or surface=asphalt (or smoothness=good or whatever), then the rule will
not set the key mkgmap:unpaved=1.
So, if you want to fix it, please add some surface=* to the affected
ways, to make the map more accurate. Theoretically, you could add some
bounds-based rules for setting the default surface of bicycle paths, but
I would recommend against doing that. I prefer more explicit than
implicit (easier for all tools that use the map data).
BTW, the "add" keyword in mkgmap style language means "set if not
already set to something". The "set" keyword simply overrides any
existing value. So, if any other rule already assigned mkgmap:unpaved to
something, this rule would not change it further:
The rule in lines is
(highway=bridleway | highway=path | highway=track |
highway=unsurfaced)
& surface!=* & tracktype!=* & smoothness!=* & sac_scale!=*
{ add mkgmap:unpaved=1 }
And BTW, we have both unpaved and paved cycleways here in Finland (and I
guess, Europe in general). There are also lots of forest paths, some of
which are rideable by bicycle, depending on the bicycle and rider, and
also the current conditions (dry/muddy/snowy/icy).
I agree with Felix that unknown should be treated as unpaved, to default
to a sane/safe value (do not send racing cycles to potentially
unrideable ways). If you do not mind entering unknown surfaces, simply
deselect the "avoid unpaved ways" routing setting.
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bicycle=use_sidepath
On Mon, Aug 17, 2015 at 03:34:26PM +0200, Felix Hartmann wrote: Definitely not I would say. It will just cause routing to break down for cyclists IMHO. Too often such sidepathes won't be connected - or maybe the sidepath is not even entered in OSM. It might not even matter if the sidepaths have been entered and connected. For long-distance routing, I believe that the Garmin Edge 705 completely ignores cycleways for the middle section of the route. Cycleways would only be considered for the first and last 5 kilometers or so. So, if you have a 50-kilometer route that would involve riding on a cyclepath next to a highway=trunk, Garmin Edge 705 would send you on a 200-kilometer detour using smaller roads. I had this happen to me a few years ago. Ways like http://www.openstreetmap.org/way/167517631 were being ignored, and http://www.openstreetmap.org/way/17065902 was tagged bicycle=no already then. That said, I guess that treating more bicycle=* values in the same way as bicycle=no will not make the situation much worse. If you want proper long-distance bicycle routing, you have to use a precalculated route (or better routing software, such as Brouter). Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bicycle=use_sidepath
On Mon, Aug 17, 2015 at 04:33:20PM +0200, Gerd Petermann wrote: I think we should only consider results of current software, means, recent maps created by Garmin or with latest versions of mkgmap and latest Garmin software (firmware or PC software). Old but still somewhat usable devices do not receive updates any more. The very last firmware update for the Edge 705 was in 2010, almost 5 years ago. So, if you can reproduce a case where Garmin software ignores restrictions, please post details, else I prefer to think that mkgmap is writing wrong img data. Unfortunately I do not have the Edge 705 any more, so I cannot post details. But I think that Thorsten Kukuk posted a plausible explanation of what probably was going on. Unfortunately it is quite complex to detect parallel roads, I already needed that for the housenumber code and found no algo. Sure. For what it is worth, detecting parallel roads could also be useful for providing better turn instructions (copying the name of the main way to the cycleway). Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] What is the idea behind --adjust-turn-headings?
On Thu, Aug 06, 2015 at 03:11:23PM +0200, Gerd Petermann wrote: I understand that this option should help to produce good driving instructions. Anyhow, I wonder if the result is really better. The two screenshots show the difference at this node: http://www.openstreetmap.org/node/21725099 This node is a 3-way T-shaped crossing, with roughly 90° angles between the 3 roads. If my memory serves me correctly, the motivation behind --adjust-turn-headings was to help in cases where you are entering a Y-shaped crossing from the bottom, and there is a very sharp angle between the branches of the Y. At the extreme, one of the branches is going straight, and the other is at some very small angle. In this case, you might want a direction such as turn left or turn right, if Garmin cannot produce a keep left or keep right direction. IIRC, without the option, when entering this cycleway ramp from the north: http://www.openstreetmap.org/node/33986539 the Garmin Edge 705 would not give any announcement that I have to turn. With --adjust-turn-headings, it would tell me to turn left. I do not have the device any more, so I cannot test this. Before I can fix the additinal problems introduced by the naming of service roads I'd like to understand if this is the intended behaviour. I would say that it is not. If you have a T-crossing with the nodes AC at the end of the horizontal section of the T and the node B at the bottom, and you are going left to right from A to C, the road names or the way how the roads are split to way segments should not matter. It also should not matter if the route A-C is bending slightly. IMO, what should matter is the difference of the angles of the roads. In this case, the angle difference between A-C and A-B is about 90°. If that angle difference were smaller than some threshold (say, 45° or maybe even 30°), then it would make sense to adjust the turn headings. Otherwise the turn directions would be simply noise. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] What is the idea behind --adjust-turn-headings?
On Fri, Aug 07, 2015 at 12:00:25PM +0200, Gerd Petermann wrote: // also helps to produce a turn instruction when the main // road bends sharply but the side road keeps close to the // original heading Oh, that would seem to be applicable for a scenario where you have a grid of highway=residential, and among them a main road (say, highway=tertiary) that is going like zig-zag within the grid. Could it be that Garmin is not issuing a turn instruction in this case, when the main road consists of a single object (with a sharp turn in it)? AFAIR, there was another option for implementing support for through_route relations, in a case where a main road goes zig-zag through a village. Is it still present in the code base? Maybe it makes this case of --adjust-turn-headings redundant? Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] OT: Edge 705 firmware hacking
Hi, On Tue, Jul 28, 2015 at 11:36:05AM +0200, Mayer Peter wrote: i saw your blog in the internet concerning edge 705. You wrote, that it is possible to make a firmware update via SD-card. Is this possible? If yes how should i do this? Just copy the GCD file on the SD card? I believe that you are referring to my post to this mailing list a few years ago. Because I use Linux on my computers, I never used Garmin's official method of updating the firmware, if there is one. I got a link to a firmware file on Garmin's web server, similar to the one in this discussion that is still available on Garmin's server: https://forums.garmin.com/showthread.php?1185-Edge-705-and-SRM Later, when more firmware updates were made available, I edited the URL and successfully downloaded newer firmware files, and then (as the above link says) copied them as gupdate.gcd to the root of the SD card. These files are long gone from the Garmin server, I think. Anyway, I saved the following files (the numbers are file sizes in bytes): 3323420 Edge605_705_260.gcd 3324700 Edge605_705_270.gcd 3325980 Edge605_705_280.gcd 3466020 Edge605_705_290.gcd 3468836 Edge605_705_310.gcd 3472932 Edge605_705_320.gcd 3479123 Edge605_705_330.gcd The files look uncompressed to me. In the end, I did not bother hacking the firmware, because I did not want to risk bricking the device. My edge shows a similar phenomenon, it can’t store any activity data on the USB mass storage but you can access its mass storage via PC / Mac. AFAIU, the Edge 705 never writes activity data to the MicroSD card. It only stores it in the internal memory, first in an internal format and then converted to the XML-based TCX format. You can store maps (gmapsupp.img), GPX routes and firmware updates on the MicroSD card by using a computer. When the Edge 705 is connected to a computer, it exports two usb-storage devices: the FAT partition of its internal flash, and the MicroSD card. Did you try a factory reset (press the buttons Power+Mode)? Or did you try pressing Power+Up? The Garmin firmware is buggy. I got some random trouble with all the above firmware versions. Sometimes it would crash when converting the stored data from its internal format to the XML-based TCX format, and I had to write a script to stitch the pieces together. Sometimes it would write some garbage to a TCX file. Sometimes it would crash while recording. Once it corrupted its internal FAT file system, and I had to carefully repair it via the usb-storage interface. A few months after that, the data lines of its USB port failed, which made the device useless for saving any GPS traces. I would like to update the firmware again but did not succeed. Did you solve your problem? I switched to an Android phone. My Edge 705 sat idle for a few years, until I sold it to a friend a few weeks ago. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] highway=footway not accessible for pedestrian?
On Thu, May 07, 2015 at 09:48:57AM +0200, Gerd Petermann wrote:
I've just noticed that the default style
treats a way with highway=footway and bicycle=yes
as a bicycle-only way, e.g.
http://www.openstreetmap.org/way/8564649
I think that is not intended.
Reason is this rule:
# Convert generic path to most specific
highway=footway snowplowing!=no
(bicycle=yes|bicycle=designated|bicycle=permissive|bicycle=official)
{set highway=cycleway; set bicycle=yes}
which changes a highway=footway to a highway=cycleway.
In the german wiki the tag highway=footway means something like
pedestrian only.
I'd like to change that rule to
highway=footway snowplowing!=no
(bicycle=designated|bicycle=permissive|bicycle=official)
{set highway=cycleway; set bicycle=yes; set foot=yes}
OK?
Yes, looks OK. I think I am the culprit for this breakage.
The reason for my thinking mistake is because there are very few
highway=cycleway without foot=yes in my area. It is like Rad weg in
German: a ghetto for human-powered traffic, to keep the real roads
free for cars.
highway=footway means pedestrian-only, so adding bicycle=yes may seem a
bit controversial. Maybe some mappers apply common sense (like in your
example), or maybe adding bicycle=yes makes sense for a short way that
marks a highway=crossing across a bigger road. Here we have such
crossings, which are connecting tertiary roads to highway=cycleway
running in parallel. They are legally footways, if you are not allowed
to ride the bike when crossing the street. If you are using such a way
to go from the tertiary road to the cycleway, for routing it would make
very much sense to allow that short way for bicycles.
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] RFC: naming unnamed roads
On Tue, May 05, 2015 at 08:17:26PM -0400, Greg Troxel wrote: The US is highly variable and both styles exist. Around me, road names often change at the town border, and if they don't the addresses usually reset. Right. The resetting of the house numbers while keeping the road name was the confusing part for me (as a tourist who does not know or notice the town borders, in areas where the towns have grown together). For extra confusion, roads are named for the town they go to, so you can be on Lexington Road in Waltham and after crossing be on Waltham Road in Lexington. That sounds like standard practice in Europe too. Agreed that this doesn't cause mkgmap/garmin problems. Yes. Nevertheless, it is good to know how things are done in different parts of the world, to avoid choosing a bad design. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Copying area tags to pre-existing POIs
On Mon, May 04, 2015 at 08:46:15AM +0200, Thorsten Kukuk wrote: Even more complicated would be something like amenity=restaurant, if somebody adds a POI and adds all tags to the building, too (I think this is bad tagging and the POI should be removed from the OSM data, but that's another problem. Would it be possible for mkgmap --areas-to-pois to copy the tags to one (or all) of the entrance POIs, instead of generating a new POI? Let us consider a building that is dedicated to a single restaurant, and has multiple entrances. Or a school building that has a complex shape and lots of doors on each side, but only one main entrance that is useable by visitors. I think that it would be best to have a POI generated for the main entrance, or maybe for all entrances. Someone could tag for a renderer and duplicating the tags (amenity, name, opening_hours, etc.) on each entrance. Then we would get a duplicate POI for the area if --areas-to-pois is used. This redundant tagging would AFAIU be the only way to get POIs on the entrances with the current mkgmap. For those who prefer a car analogy: parking=multi_storey or parking=underground lot that has an entrance. OK, for cars, the entrance and exit driveways are usually explicitly mapped, with appropriate access tags. For pedestrian routing, some fences or locked gates might be missing or ignored by the routing, and therefore you really could benefit from knowing which entrance to use, instead of being told where the center of the building or area is. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] access rules
On Fri, Mar 06, 2015 at 10:11:27AM +0100, Gerd Petermann wrote: I'd like to have a special tag with the meaning xxx access is allowed, all other is forbidden so that one doesn't have to set a lot of tags to no just to make sure. What about combined ways: highway=path bicycle=designated foot=designated segregated=no You have a traffic sign for that in Germany too, don’t you? (Even though it is not common.) BTW, in Finland, highway=pedestrian is allowed for bicycles with maxspeed=20. In Germany, it is pedestrian-only. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] FW: AW: RE: computing power mdx/mdr
On Thu, Feb 26, 2015 at 10:47:42PM +, Steve Ratcliffe wrote: Japanese almost certainly doesn't work with the global index anyway. Right. For Japanese, MeCab has a different approach for fulltext search, applying morphological analysis. I wonder if Garmin supports anything like that on its devices, or if this type of indexing makes sense for the street naming schemes that are used in Japan. If not, there is not much that a map generator can do. BTW, in the patch there was a typo in a method name: getInitalPart() should be getInitialPart(). Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mixed index branch merge
On Sun, Feb 15, 2015 at 01:02:37AM +0100, Colin Smale wrote:
But, is this really an issue? Street signs may be in two or more
languages, saying Foo Street and Rue Foo for example. Can anyone
name a multi-lingual area where a stopword in one language would be a
non-stopword in the other language?
de is the in Dutch, of in French - both (candidate) stopwords in
their own way, but you would want different rules for keeping or
omitting de in street names.
It also means South in Welsh, which you probably would not want to
omit in most cases.
Is there an administrative area where both Welsh and Dutch or French are
used in street name signs? I would not expect so.
AFAIU, your suggestion wrongly assumes that only one language will be
used in a given region. And I think it should be based on
administrative regions, not necessarily countries.
I intended to suggest that each area would have a single default
language. Main reason is to select the correct stopword treatment in
the absence of explicit name:xx tags. In most cases roads are just
tagged with name=* - so this mechanism would define the mapping of
name to a language. Then you only need a single stopword treatment
for the language, which can be shared by all territories which use
that language.
Right, this suggestion should be a reasonable default, if it is
selectable by any admisitrative level (such as country, state, province
or municipality).
How would you represent an area that has multiple official languages
that can appear on street signs? I think that the OSM convention would
be something like this:
{ set mkgmap:lang:fi=yes; mkgmap:lang:sv=yes; }
or the (more tricky for our style rules)
{ set mkgmap:lang='fi;sv' }
Well, I assume that the maps produced by mkgmap are targeted to a
language (or ordered list of languages) chosen by the mkgmap user.
I do not think that it is always a reasonable assumption. Most areas in
Finland use Finnish as the primary official language. For some places or
streets in a Swedish-speaking area there could exist Finnish names, but
maybe the Finnish-speaking minority is so small that the signs are only
in Swedish. It could be more useful to have the street names in the same
language on the map as you have on the signs. Only if the street signs
displayed each language, it would make more sense to let the user to
override the primary language (name=* labels) at map translation time.
Similarly, when travelling in former Finnish-language areas that were
made part of the Soviet Union, it could be more useful to have the
current Russian names on the map, because the street signs would not be
in Finnish any more.
I can't imagine someone wanting all the languages in the map at the
same time. Can the Garmin format even handle that?
AFAIU, only the Garmin NT format (which mkgmap does not support) allows
you to define labels in multiple languages.
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mixed index branch merge
On Sat, Feb 14, 2015 at 09:57:49AM -0200, Alexandre Loss wrote: So, my suggestion is exactly that: allow the users to define their own stopwords. Yes, I agree on that. But, could it be done in the style files based on the administrative boundaries, similar to how the admin levels are processed? This would still allow customization, while providing a sanely working default style. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mixed index branch merge
On Sat, Feb 14, 2015 at 01:23:18PM +0100, Colin Smale wrote: The stopword processing should be language-specific and not (solely) based on admin boundaries... One man's stopword is another man's significant proper name. Sure, but I would guess that there is an admin boundary around a bilingual or multilingual area where you would not want to use the normal stopwords for any of the languages. Generally, I would agree with you that country!=language, and I dislike misusing a national flag for designating language. But, we are only talking about official street name signs here. Can you think of any actual examples where one language's stopword is another language's significant proper name? Such that both languages can be used in the street name signs within the same admin boundary? In the latter case the roads still end up in the right place in the index when searching. There is another aspect as well: multi-part street names, often using titles and personal names of local heroes. Right. In the languages that I am aware of (other than Spanish and French and maybe Italian), the stopwords tend to be at the end, not at the start of the name. But still, you would not want to get a lot of [stopword], local hero name entries somewhere in the index, for each name=local hero name [stopword] entry. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mixed index branch merge
On Sat, Feb 14, 2015 at 03:57:21PM +0100, Colin Smale wrote:
What about multi-lingual countries such as Belgium or Switzerland?
Or multi-lingual cities, such as Montréal in Canada?
But, is this really an issue? Street signs may be in two or more
languages, saying Foo Street and Rue Foo for example. Can anyone
name a multi-lingual area where a stopword in one language would be a
non-stopword in the other language?
For example, could there be a highway=* with name=Rue Street in a
French/English area? I would not think so.
For what it is worth, there are a lot of bilingual street signs in
Finland, using Finnish (name:fi), Swedish (name:sv) or in the north,
Sámi (name:se). It depends on the share of the minority population
whether multiple languages are used. The majority language appears first
in the signs. So, usually it is Finnish first, then Swedish, or Swedish
first, then Finnish. Sometimes the signs could be Finnish or Swedish
only.
How about this (sorry the abbreviations are wrong but it is only to
illustrate my point):
mkgmap:country=POL {set mkgmap:lang=polish;}
AFAIU, your suggestion wrongly assumes that only one language will be
used in a given region. And I think it should be based on administrative
regions, not necessarily countries.
How would you represent an area that has multiple official languages
that can appear on street signs? I think that the OSM convention would
be something like this:
{ set mkgmap:lang:fi=yes; mkgmap:lang:sv=yes; }
or the (more tricky for our style rules)
{ set mkgmap:lang='fi;sv' }
If the stopwords were also defined to be regular expressions, then it
could also handle prefixes and suffixes as well as whole words.
I agree that defining stopwords as regular expressions would provide
some necessary flexibility. Like someone said, we do not want to omit
Straße (or other stopwords) at the start of a street name in languages
that usually put the stopword at the end of the name. But, in French and
Spanish the stopword is always at the start of the name. An anchored
regexp (\Straße$ or ^Calle\) would nicely express this.
Maybe the regexp could also facilitate a rewriting system for
abbreviating the index entries, such as replacing street with st in
English, Straße with Str in German, puiestee with pst in
Estonian, katu with k in Finnish and so on.
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mixed index branch merge
On Thu, Feb 12, 2015 at 01:24:29PM +, Steve Ratcliffe wrote: So finally I will merge the mixed index branch. I believe that the database terminology for this is 'inverted index' or 'fulltext index'. I think it would be best to selectively enable it per country along with lists of names to avoid. This would be best done by people from or familiar with the countries in question. In fulltext search, these are called 'stopwords'. It might not be necessary to do anything to for countries where street names are commonly written as a single word. Example: Main Street would be Hauptstrasse in German, Huvudgatan in Sweden and Päätie in Finnish. Only if the first part of the street name is a proper name such as a person's name, the second part could be written as a separate word, separated by a space or dash. That said, I guess it would still make sense to introduce some stopwords. Words that I can think of: Swedish: gata, gatan, gränd, gränden, stig, stigen, (stråk, stråket) Finnish: tie, katu, polku, kuja, (raitti, taival) German: Straße, Strasse, Weg, Allee, Chaussee Estonian: mnt, maantee, tn, tänav, pst, puiestee In Estonia, it seems to be common to write the tn, mnt or pst as a separate word. I could be missing some stopwords in Estonian and for German-speaking countries. Also, it could be that the French loan words Allee and Chaussee are sometimes accented. The Finnish and Swedish words that I have put in parenthesis should be very rare, typically used for ways for non-motorized traffic. I don't think that including them would pollute the index much. You might in fact want to search for such a name when you are looking for a nice walking or cycling route (i.e., you expect there to exist some random-famous-person-name-stråket, but you do not know the random name). Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Solution to show transliterated name if no other ascii name exists
On Tue, Jan 13, 2015 at 10:01:04PM +0100, Walter Schlögl wrote: Do you know, if the logfile can only be written in ANSI coding, or if there is a way to use unicode for logfiles? By ANSI or Ansi, Microsoft used to refer to their (or IBM's) proprietary Code Page 1252 encoding, which is a superset of ISO 8859-1 aka ISO Latin 1. To add some confusion, some software is referring to cp1252 as latin1. That said, an early version of ISO 8859-1 might have been an ANSI standard. It was used already in the 1980s on the Commodore Amiga, and on Digital computers and terminals (DEC Multilingual Character Set). As far as I know, there is no restriction of how files can be written in contemporary operating systems. Even on Windows, it is normal nowadays to use UTF-8 in file contents. Some Windows software could be happier if the file begins with a Byte Order Mark (BOM), but I do not think it is necessary. Given that OSM has always used the UTF-8 encoding, it would seem easiest to use UTF-8 in the log file output. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Solution to show transliterated name if no other ascii name exists
On Mon, Jan 12, 2015 at 10:06:00PM +, Steve Ratcliffe wrote:
Hi
{ add mkgmap_int_name='${name|ascii:}' }
This is now included in r3409. There is no longer any need for
the ':', so you can just write ${name|ascii}
Side note: In src/uk/me/parabola/imgfmt/app/labelenc/ there are two
implementations of the Transliterator interface: SparseTransliterator
and TableTransliterator. I see no references to Greek or Cyrillic in any
file in the whole directory. I guess we might try to do something
(Pinyin?) as Chinese transliteration, if the Java framework does not
already do that for us.
I wonder if the mkgmap transliteration is compatible with the
international standards, such as ISO 843 (Greek) and ISO 9 (Cyrillic).
Also national standards exist for Cyrillic transliteration.
Quoting a message by Χάρης Καραχριστιανίδης on the OsmAnd mailing list:
https://groups.google.com/forum/#!topic/osmand/7PTV_nOhNUw
According to this link
https://wiki.openstreetmap.org/wiki/Multilingual_names#Greece ISO
843:1999 should be followed for trancription of Greek Names. So for
example Βύρωνος ( don't know if you can read Greek letters) should be
Vyronos and not Buronos. As I can see almost all Greek streets are
wrongly transcribed.
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multi-word street search
On Wed, Dec 17, 2014 at 10:30:30AM +, Steve Ratcliffe wrote: On 16/12/14 23:09, Andrzej Popowski wrote: I guess this is offset greater than 127 coded on byte. I hope Garmin treat offset as unsigned byte, so you could support values up to 255. And maybe limit end value in addStreet function, unless size of label is already limited. You really have names over 127 characters in length? I will add checks assuming that 255 is the max. Could you see if it works or if we have to limit to 127. 127 bytes in UTF-8 can be significantly less than 127 characters (31 characters if all characters use 4 bytes). Maybe CJK names are not typically using that many characters. But perhaps Arabic or Hebrew or Indian exclusively uses 3-byte characters? In that case, 127 bytes would be only 42 characters, which is not impossibly long. I am under the impression that European scripts use at most 2 bytes per character in UTF-8. 63 characters would seem more than long enough for my Finnish taste. And Finnish uses close to 1 UTF-8 byte per character in the average. :) Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Non-rectangular tiles
On Thu, Nov 27, 2014 at 07:27:12AM +0100, Thorsten Kukuk wrote: On Thu, Nov 27, Steve Ratcliffe wrote: I was meaning to write a message about this for a while and since the thread for drive-on-left/right has brought this up already today and since it is a mkgmap birthday (8 years!) this might be a good time to set the ball rolling. Happy Birthday mkgmap! And a big thanks to all developer who made this possible, mkgmap and the OSM maps for GARMIN are really a big plus for me. +1. While I have gone a little inactive, mkgmap is still useful. The USB data transfers on my Edge 705 died some years ago, so I cannot use it for mapping. (But I do not update OSM that much either, given that it already is good enough for me.) I have been using OsmAnd on a smartphone. In some ways, the old Garmin is still better. I am sure that it can be done, but it is a large task and will need more than one person working on it. If there is any interest I shall outline my thoughts tomorrow. I would be very interested in this. Me too. It would be nice to have properly shaped polygon around the map of Finland that I still update every now and then. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Doubt about administrative boundaries
On Wed, Sep 03, 2014 at 08:52:05PM +0800, Ervin Malicdem wrote:
You need to extract boundary relations data before telling mkgmap to
process it.
There are 2 different use cases. One use case is to associate each POI
or road (or address index entry) with an administrative area that it is
contained in. That is what I would expect the boundary processor to be
for. But, this somehow always seemed to work for me (Garmin Edge 705)
even without using the boundary processor.
The older use case is to generate visible boundary lines in the map.
That is what this rule in the 'relations' file of the default style is
for:
(type=boundary | type=multipolygon) boundary=administrative name=*
{ apply
{
set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' |
'${name}';
}
}
This combined with these rules in the 'lines' file used to do the trick:
boundary=administrative { name '${mkgmap:boundary_name}' }
boundary=administrative admin_level3 [0x1e resolution 12]
boundary=administrative admin_level5 [0x1d resolution 19]
boundary=administrative admin_level7 [0x1c resolution 21]
boundary=administrative admin_level9 [0x1c resolution 22]
boundary=administrative [0x1c resolution 22]
boundary=national [0x1e resolution 17]
boundary=political [0x1c resolution 19]
Near the place I live, there are boundary lines that are boundaries on
multiple admin_levels. For example, this section
http://www.openstreetmap.org/way/237098468
belongs to 4 boundary relations, and I would expect all 4 names on the
line in the Garmin screen, in some order:
Vantaa/Sipoo/Helsingin seutukunta/Korson suuralue
At some point of time (maybe as a result of WanMil working on the
POI-to-area mapping a couple of years ago), I think that this stopped
working, and the line only got tagged with only one of the name. With a
quick look into a recently generated gmapsupp.img, I did not see any
occurrences of / that would seem to be for a boundary line.
The way 237098468 itself does not carry a name tag, but now I see that
it carries the tag admin_level=7. The 'apply' rule in the 'relations'
file is only copying the name across, but it does not make any effort to
copy the admin_level. Maybe it should? Maybe it should also copy the
boundary=administrative tag to the line if it is not already there.
This is a tricky situation. I think that the proper thing to do would be
is to clone the boundary=administrative member way if it does not carry
a boundary=administrative tag. Then, the tag would be added to the
cloned way. In that way, you would get both the boundary line and say, a
river or a highway that is part of a boundary. An alternative might be
to simply add the boundary=administrative tag to the original way, and
to use 'continue_with_actions' in the 'lines' file.
When it comes to setting the admin_level on the relationship members, it
is even more tricky. I guess that one sensible action would be for the
'apply' rule to overwrite the admin_level tag on the member way, if the
value on the relation is smaller than the value on the way. In that way,
the boundary=administrative way would be tagged with the lowest (most
significant) applicable admin_level.
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Doubt about administrative boundaries
On Mon, Sep 01, 2014 at 09:05:44PM -0300, Nelson A. de Oliveira wrote: Does mkgmap support administrative boundaries defined only by relations? (ie, there isn't any kind of tag in the ways) This at least used to work. I wrote the apply rules for getting names on the boundaries from the relations, separated by / or ,. It might have been broken since I wrote the code. For this code, I introduced the $(name) syntax, so that I could append to the existing name. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MIssing public transport stops in default style
Hi Carlos, Thanks for the revised patch! It looks OK, and it resulted in a slightly bigger map of Finland than before, with the same source data. Committed as revision 3334. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MIssing public transport stops in default style
On Wed, Aug 20, 2014 at 11:04:02PM +0200, Carlos Dávila wrote: According to OSM wiki bus stops can be tagged as bus_stop=yes or as public_transport=platform + bus=yes (or both ways), but current default style only catches the first case. The same can be said about tram stops. Attached patch adds rules for the second way of tagging. Thanks! I think that this can be simplified a little: ( public_transport=platform (bus=yes | tram=yes) ) | (highway=bus_stop | railway=tram_stop | railway=halt | railway=station) I do not think that we need the (bus=yes | tram=yes) here. These rules are only setting the name for any kind of stop. They are not yet creating the POI. -highway=bus_stop [0x2f17 resolution 24] +( public_transport=platform bus=yes ) | highway=bus_stop [0x2f17 resolution 24] I would just group bus and tram stops together here, but move the rule after railway=* so that the railway-specific rules would fire first: @@ -226,7 +226,7 @@ railway=halt [0x2f08 resolution 23] railway=station [0x2f08 resolution 22] -railway=tram_stop [0x2f17 resolution 24] +( public_transport=platform tram=yes ) | railway=tram_stop [0x2f17 resolution 24] Here, I would remove your + line and instead write: public_transform=platform rail=yes [0x2f08...] highway=bus_stop|highway=tram_stop|public_transport=platform [0x2f17...] I did not check if rail=yes is a valid tag. In this way, if a public_transport=platform is not rail=yes, it will be assigned the type 0x2f17. All railway stops would be 0x2f08, except tram stops which are 0x2f17. Can you submit a revised patch for this? Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] barrier=lift_gate
Hi Gerd,
On Fri, Aug 08, 2014 at 10:57:38PM -0700, GerdP wrote:
Hi all,
I noticed that the default style is a bit strange regrading barriers:
The barrier at node
http://www.openstreetmap.org/node/1597509392#map=19/52.21425/8.81559
has an influence on routing (with --link-pois-to-ways), but it is not
displayed
in the map.
The reason is that we use barrier=* when we evaluate the effect on routing,
but we display only specific barriers:
barrier=bollard | barrier=bus_trap | barrier=gate [0x660f resolution 24]
barrier=block | barrier=cycle_barrier | barrier=stile | barrier=kissing_gate
[0x660f resolution 24]
I think we should display all barriers which have an effect on routing,
but I am not sure what to change in the style.
Any suggestions?
What about the following:
barrier=* { set mkgmap:barrier=yes } [0x660f resolution 24]
Then, change the internal processing to look for mkgmap:barrier instead
of barrier. In this way, certain barriers can be ignored by style file
authors.
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] barrier=lift_gate
On Mon, Aug 11, 2014 at 12:18:03PM +0200, Gerd Petermann wrote: sounds not bad. We could remove the --link-pois-to-ways option. The style author can decide whether to display the barrier and only those nodes with mkgmap:barrier=yes are considered for routing. Right. Could the processing of mkgmap:barrier also consider other tags that might be set on the node? For example, there could be a shallow steel rail on the road side that is trivial to cross for the majority of pedestrians. I guess it should be considered as a barrier for bicycles, even though it is possible to lift the bicycle over and continue riding. Currently these two paths are detached from the main road and the end nodes are tagged as noexit=yes, which prevents even pedestrian routing: http://www.openstreetmap.org/node/443718771 http://www.openstreetmap.org/node/443718772 I think that I should tag the nodes with barrier=something,foot=yes and connect the paths to the main road, and expect the routing to only be allowed for pedestrians. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] splitter r334 does not compile
I got this with splitter r334. With r333, the code compiles successfully: [javac] splitter/src/uk/me/parabola/splitter/Main.java:501: error: constructor PolygonDescProcessor in class PolygonDescProcessor cannot be applied to given types; [javac] polygonDescProcessor = new PolygonDescProcessor(); [javac] ^ [javac] required: int [javac] found: no arguments [javac] reason: actual and formal argument lists differ in length An int resolution parameter was added to the constructor in r334. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Parameterized styles and macro languages
Hi Andrzej, On Mon, May 12, 2014 at 03:15:46PM +0200, Andrzej Popowski wrote: Hi Colin, Users can customise the program and styles or develop their own, but there is no mechanism to support sharing the nuances of each type of device within the distribution. I understand the problem but I don't think mkgmap code or default style is a right place to solve it. We could expect more flexibility to create conditional styles from mkgamp, but any hardcoded dependency on Garmin hardware would be a nightmare to maintain. Well, I think that we could solve it in the default style to some extent. The default style could add one layer of abstraction by using symbolic names instead of numeric type codes in the actions, and the user would take advantage of this if needed. The solution would be parameterized or conditional styles and something similar to what the C preprocessor supports with the -D and -include options. Something like this: java -jar mkgmap.jar -D campsite=0x1234 ... or java -jar mkgmap.jar -include edge705.h ... where edge705.h would contain stuff like #define campsite 0x1234 (or something equivalent in a syntax that is not too different from the current mkgmap style language) Myself, I am not interested in device-specific rules, but I would like to have some parameters that would allow unnecessary detail to be pruned. There could be parameters for minimum size for landuse=* or natural=* or building=* polygons, or the minimum length of highway=service to render in each resolution level. The parameters could also include the list of resolutions to generate. I am not sure if the mkgmap core language should include a parameter substitution mechanism or a macro language. Perhaps we could leverage an external tool, such as http://pmp.sourceforge.net/ which implements the m4 macro language in Java, including ant integration. The mkgmap distribution could include a parameterized build.xml for compiling a map with ant. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Building vs way in default style
On Mon, May 05, 2014 at 12:58:58PM -0700, GerdP wrote: Hi Steph, I think mkgmap creates a shape for the building and another one for the water. It seems that without a type file the water has higher priority. It is possible to detect that situation and cut the shape of the building out of the shape for the water, but that will require a lot of CPU, so I think it's not a good idea. After looking at http://www.openstreetmap.org/way/40217747 I have to agree that we should not do this by default. It could be misleading to cut out bridge polygons from the waters that they are crossing. Someone who uses the map for kayak navigation (or, say, ice-skating or cross-country skiing in the winter) could want to see the water polygon without any gaps, if the bridge is high enough. I think that ideally, there should be multiple map layers, enabled or disabled by the user. The base layer would contain the natural=* or landuse=*, and a special man-made objects layer would show building=* and man_made=* on top of the base layer. This is doable with the Garmin format (in mkgmap by using one style per output layer). Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] r3174 in via_ways branch
On Tue, Apr 08, 2014 at 08:46:34AM +0200, Gerd Petermann wrote: I think the branch is ready for trunk now. Me too. While I did not test routing, it seems that you did that on behalf for me (in Finland). I checked the warning messages, and I think that they all are clear and warranted now. I did a few more tests regarding turn restrictions with via ways. It seems that they are working, but the effect is minimal. In Finland, they are (now) used only in no_u_turn restrictions, and the Garmin algo seems to avoid these u-turns anyway if alternatives are available. I guess that the impact is bigger in places like California, where they have dual oneways and they only allow left-turns and U-turns in certain intersections. Then it is common that you will have to drive slightly past your destination, make a U-turn a few intersections later, and then make a right-turn. I have not checked the mapping detail in those areas. If these dual-oneways are already mapped as such in OSM (instead of being mapped as one two-way street), no turn restrictions would be needed. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] r3165 in via_ways branch
Hi Gerd, Yes, I found an error in the check. Thanks, this message is no longer being issued for this relation. Here is another: 2014/04/05 18:38:10 WARNING (RoadNetwork): 63240002.osm.pbf: Turn restriction (only_right_turn) http://www.openstreetmap.org/browse/relation/423035 (at http://www.openstreetmap.org/?mlat=60.168471mlon=24.934714zoom=17) restriction ignored because all possible other ways are wrong direction in oneway The way straight ahead is marked as oneway=yes that prohibits entry, but it carries bicycle:oneway=no, psv:oneway=no. Similarly, the turn restriction is tagged as except=psv;bicycle. While it is a redundant restriction, I suspect that this form of tagging is not being recognized by the via_ways branch. Would mkgmap now be refusing bicycle routing straight ahead? At least the message is a bit misleading or imprecise. I understand that the ; delimiter is troublesome. How should this be tagged? restriction:bicycle=no? A future improvement could be to handle no_through_route or no_through_driving restrictions, such as relations 2886802 and 2886879. They are not describing the complete route; it is a bit ambiguous what is meant by the relations (and the traffic signs). If I got that right, the meaning is that you are not allowed to drive into an area if you plan to drive through it. In my eyes this should be handled with the tag access=destination ? It might not be that simple, because my understanding is that access=destination would prohibit any through-routes, while only certain through-route are being prohibited by the traffic sign. Looking more closely at relation 2886803, the idea seems to be this: A | | Mestarintie | B---+---+ | | | C | Panuntie If you turn from A down to Mestarintie, you must not turn at crossing B to Panuntie (C), but instead you must continue straight on to the left. (If you stop for a while somewhere between A and B, then it is OK. It is somewhat fuzzy and ambiguous, and seldom enforced, I guess.) There could be some alternative routes A-B-C in that subnet, and I guess that the no_through_driving should still apply, even if you did not use the shortest route A-B-C. An approximation of this restriction could be to prohibit driving only on the shortest route A-B-C. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] r3165 in via_ways branch
Hi Gerd, one more annoyance: I suppose that restriction relation 3297476 should be unrecognized (type=restriction,restriction=no_through_driving). If mkgmap does not handle this restriction type, it should issue only one message for it, unsupported restriction no_through_driving. Instead, mkgmap is now issuing two messages, about the via ways not being connected. (If mkgmap is supporting this restriction type, then these messages are OK to issue.) This is a similar restriction as the one I described in more detail. This relation even carries a note explaining that the role=via is not well-defined. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] r3165 in via_ways branch
On Thu, Apr 03, 2014 at 09:28:06AM +0200, Gerd Petermann wrote: I think r3165 is ready for a deeper test. Here is a restriction that forbids turning to left, to highway=service,oneway=yes (not against oneway direction): 2014/04/04 15:02:52 WARNING (RoadNetwork): 63240008.osm.pbf: Turn restriction (only_straight_on) http://www.openstreetmap.org/browse/relation/905336 (at http://www.openstreetmap.org/?mlat=63.678088mlon=22.715307zoom=17) restriction ignored because it forbids only u-turn Also, would it be possible to split the following warning message ignored because A or B into two messages: ignored because A and ignored because B? ... restriction ignored because all possible other ways are wrong direction in oneway or not accessible for restricted vehicles A future improvement could be to handle no_through_route or no_through_driving restrictions, such as relations 2886802 and 2886879. They are not describing the complete route; it is a bit ambiguous what is meant by the relations (and the traffic signs). Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Turn restriction angle checks
On Sun, Mar 30, 2014 at 02:34:07PM +0200, Gerd Petermann wrote: BTW, I accidentally loaded a relation somewhere in Russia and downloaded the surroundings. There were lots of no_u_turn on every crossing of a major road. That kind of micro-mapping does not exist over here; I guess that mappers expect people to apply common sense and not make a u-turn as soon as the navigator suggests it, no matter what. I found an example of this in Finland. IMO, these relations should simply be ignored, maybe emitting a NOTE or INFO (not WARNING): 2014/04/01 08:03:24 SEVERE (RoadNetwork): 63240002.osm.pbf: Turn restriction http://www.openstreetmap.org/browse/relation/1785864 (at http://www.openstreetmap.org/?mlat=60.224055mlon=24.995477zoom=17) check special case from = to arc Normally the navigator should not generate routes where you do a U-turn like this. Even if it did, the driver should know to make the U-turn at the next convenient place where it is both practical and not forbidden. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Turn restriction angle checks
Hallo Gerd, On Tue, Apr 01, 2014 at 03:54:14PM +0200, Gerd Petermann wrote: just to make sure: The example shows a no_u_turn restriction where from way and to way are equal and a via node is used. Are that the criteria which should tell mkgmap to emit an info and ignore the restriction? Why not a warning? I'd say all correct restriction relations which are ignored should produce a warning. Yes, this is a restriction=no_u_turn, with the same way in role=to and role=from, and one of the way endpoints being the role=via node. You are right, it could be a warning as well. The warning message should mention the restriction type and that the from,to ways are equal. The warning could then be filtered out with a grep -vf script (as long as it is for restriction=no_u_turn), or the map data could be reviewed and edited, possibly after consulting the mapper, the wiki, or the applicable 'authorities'. Marko PS: Yesterday and today I addressed most warnings from via-ways -r3143 for Finland. Tomorrow it should complain very little. I left this no_u_turn relation unchanged. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Turn restriction angle checks
On Sat, Mar 29, 2014 at 08:49:53PM +0200, Marko Mäkelä wrote: On Sat, Mar 29, 2014 at 08:05:15AM -0700, GerdP wrote: the via-ways branch is almost done I just cloned and built it, and already addressed one error message that it emitted (redundant turn restriction, prohibiting turn against oneway direction). In the same crossing, there was a wrong turn restriction that an automated check might detect too: \ (oneway) \ On a crossing like this, there is a very sharp turn (135 degrees to right from the diagonal road to the horizontal road), and the turn restriction said no_left_turn. I guess it should have said no_right_turn. I changed it to only_straight_on (role=from and role=to being the diagonal road). Maybe the patch is actually trying to address the above situation. The above case was version 1 in http://www.openstreetmap.org/relation/2350374/history I think that the new code is generating noise for a U-shaped oneway handles on major twoway roads (a parking lane for making a break, only accessible from one direction of travelling). Here is an example: 2014/03/29 19:56:21 SEVERE (RoadNetwork): 63240005.osm.pbf: Turn restriction http://www.openstreetmap.org/browse/relation/298645 (at http://www.openstreetmap.org/?mlat=61.346723mlon=26.206187zoom=17) check special case from = to arc 2014/03/29 19:56:21 SEVERE (RouteNode): 63240005.osm.pbf: check: old code would have selected wrong arc from road 42859595 instead of road 32485453 2014/03/29 19:56:21 SEVERE (RoadNetwork): 63240005.osm.pbf: Turn restriction http://www.openstreetmap.org/browse/relation/298646 (at http://www.openstreetmap.org/?mlat=61.346238mlon=26.204694zoom=17) check special case from = to arc These two relations are forbidding a U-turn via this handle. I agree that it is more intuitive to map this with only_straight_on, but at the same time I think that this should only be a WARNING, not SEVERE. I will be replacing this kind of situations with only_straight_on, and I think that a WARNING is OK. But, I think that mkgmap should generate the same routing graph with only_straight_on and no_*_turn (with different role=to ways, of course). Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Turn restriction angle checks
On Sun, Mar 30, 2014 at 04:45:35AM -0700, GerdP wrote: Hi Marko, Marko Mäkelä wrote I think that the new code is generating noise for a U-shaped oneway handles on major twoway roads (a parking lane for making a break, only accessible from one direction of travelling). Here is an example: when the message contains the word check it is for me. It means that I plan to verify that mkgmap does the right thing. I'll remove them later. OK. But, like I said, a warning for this would be nice. The only_* looks better in JOSM and I suppose is easier to understand too, than the no_*. Here is one more strange message (no_u_turn with a via way). I see nothing wrong with the way: 2014/03/29 19:56:21 WARNING (RestrictionRelation): 63240005.osm.pbf: can't add restriction relation 532033 type no_u_turn Maybe the two oneway lanes of the road were merged to other ways, so that in the mkgmap routing graph, the two oneways and the via way form a loop of three ways? But still, the no_u_turn should make sense. Relations with access tags can sometimes be hard to understand, such as relation 2996233, which is type=no_u_turn, motor_vehicle=destination. I think that it would be better to avoid turn restrictions and tag the ways instead. That could be done in this case too. I will ask the mapper, because the role=to way looks like a stub. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Turn restriction angle checks
On Sun, Mar 30, 2014 at 02:05:08PM +0200, Gerd Petermann wrote: If I get that right the via way is a oneway going into the wrong direction. Oh, you are of course right. I will move the restriction to the proper ways. yes, I think mkgmap should try to detect unclear cases and ignore those restrictions. IMO, mkgmap should not silently ignore anything. We should generate a warning too. BTW, one more case that I do not know if you are handling yet: Issue a warning if the result would not be any different if the turn restriction did not exist. This is not only about oneway direction. For example, if there is only_straight_on on a road with no junction, a warning should be issued. BTW, I accidentally loaded a relation somewhere in Russia and downloaded the surroundings. There were lots of no_u_turn on every crossing of a major road. That kind of micro-mapping does not exist over here; I guess that mappers expect people to apply common sense and not make a u-turn as soon as the navigator suggests it, no matter what. I think that no_u_turn restrictions are somewhat a matter of a local convention. In the US it is common to forbid left turns and U-turns except in a few junctions. In Finland, that practice only exists on some major through-routes in cities. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Turn restriction angle checks
On Sun, Mar 30, 2014 at 05:11:43AM -0700, GerdP wrote: GerdP wrote If I get that right the via way is a oneway going into the wrong direction. forget that, I was mislead by the OSM renderer. It is probably an error in the branch. No, it was wrong. I moved the relation one step further in the crossing. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Turn restriction angle checks
On Sat, Mar 29, 2014 at 08:05:15AM -0700, GerdP wrote: the via-ways branch is almost done I just cloned and built it, and already addressed one error message that it emitted (redundant turn restriction, prohibiting turn against oneway direction). In the same crossing, there was a wrong turn restriction that an automated check might detect too: \ (oneway) \ On a crossing like this, there is a very sharp turn (135 degrees to right from the diagonal road to the horizontal road), and the turn restriction said no_left_turn. I guess it should have said no_right_turn. I changed it to only_straight_on (role=from and role=to being the diagonal road). Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] conditional includes in style
First, the conditional rules or includes sounds like a good idea. I
guess we should only allow the new syntax for key=value or maybe key=*.
Should we introduce a new type of keys (global keys) that are not
associated with any OSM object?
Or, should the global keys be the default on every object? For example,
after
java -jar mkgmap.jar --add-default-way-tag=name=unknown
every OSM way that did not already carry a name=* tag would be tagged
with name=unknown.
On Thu, Mar 27, 2014 at 12:15:14PM +0100, Andrzej Popowski wrote:
2. Allow for user defined tags in mkgmap options, for example:
mkgmap.jar --style-option=topo;cycleways ...
; would be a bad choice for a delimiter, because it is a shell
meta-character in the conventional Unix shells (separating commands when
you do not want to use line breaks).
Also, I think that the option should be split already on the command
line, like this:
java -jar mkgmap.jar --style-option=topo --style-option=cycleways ...
In many Unix shells, you can use short-hand notation which would be
expanded to the above by the shell:
java -jar mkgmap.jar --style-option={topo,cycleways}
Best regards,
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] conditional includes in style
On Thu, Mar 27, 2014 at 07:59:24PM +0100, Felix Hartmann wrote:
That is also quite nice, my main problem with this approach is - can
we by now assume that the mkgmap:country tag is 99.9% available
correctly when using precompiled bounds?
[snip]
if ( mkgmap:country=DEU ) {
include 'deu_highway_rules';
}
Would this mkgmap:country be assumed to be constant for all map objects?
If mkgmap builds a rectangular map tile that includes a bit of Germany,
Austria and Switzerland, would this include be executed unconditionally,
and each rule in it would be prefixed with the condition
mkgmap:country=DEU ?
If the include statement is dynamic, what if the first objects in the
OSM extract happen to be outside Germany? Would you then skip the
include for all of the map tile, skipping it for the German part of the
tile? If the first objects are inside Germany (mkgmap:country=DEU
holds), would the rules be applied to all subsequent map objects, no
matter if mkgmap:country=DEU holds for them?
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] add-pois-to-areas
On Sun, Mar 23, 2014 at 12:39:27PM +0100, Andrzej Popowski wrote: For example, a parking facility or a building could be tagged both as a point at the entrance, and as an area. This is against OSM good practice, see recommendations: http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element I do not think that it is a case of defining multiple elements for one feature. If we think of a building, the shape of its outline is one feature, and the location of the main entrance is another. Knowledge of both is needed in order to find a route. You cannot normally walk over or through a building, and you can only enter it via an entrance. Therefore, it could be misleading to route to a POI in the middle of the building outline. I guess, that it's not easy to reliable detect duplicates. Maybe better correct problem at source? AFAICT, the source of the problem is the area-to-POI conversion, which does not take into account that a more accurate POI (at the boundary of the area) exists. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Turn restrictions with role=via ways
Hallo Gerd,
On Sun, Mar 23, 2014 at 06:16:27PM +0100, Gerd Petermann wrote:
I've created a new branch via_ways to support this.
It is nearly done, but I have to find solutions for
some edge cases like via ways that cross tile boundaries.
Also some routines like RoadMerger are not yet fully tested.
OK, let me know when you would like some testing.
FWIW, there were 4 relations with role=via ways that were not no_u_turn
in Finland. I removed or replaced all of these today:
$grep 'via' ways are not supported mkgmap.log.0|grep -v no_u_turn
2014/03/24 15:25:06 WARNING (RestrictionRelation): 63240004.osm.pbf:
Turn restriction http://www.openstreetmap.org/browse/relation/2640984
(at http://www.openstreetmap.org/?mlat=61.510688mlon=23.777567zoom=17)
sorry, 'via' ways are not supported - ignoring restriction
[type=restriction,restriction=no_left_turn]
2014/03/24 15:25:22 WARNING (RestrictionRelation): 63240002.osm.pbf:
Turn restriction http://www.openstreetmap.org/browse/relation/1767298
(at http://www.openstreetmap.org/?mlat=60.20mlon=25.120266zoom=17)
sorry, 'via' ways are not supported - ignoring restriction
[type=restriction,restriction=only_straight_on]
2014/03/24 15:25:22 WARNING (RestrictionRelation): 63240002.osm.pbf:
Turn restriction http://www.openstreetmap.org/browse/relation/67571 (at
http://www.openstreetmap.org/?mlat=60.168673mlon=24.935049zoom=17)
sorry, 'via' ways are not supported - ignoring restriction
[except=psv;bicycle,type=restriction,restriction=only_left_turn]
2014/03/24 15:25:22 WARNING (RestrictionRelation): 63240002.osm.pbf:
Turn restriction http://www.openstreetmap.org/browse/relation/1745548
(at http://www.openstreetmap.org/?mlat=60.190691mlon=24.962903zoom=17)
sorry, 'via' ways are not supported - ignoring restriction
[type=restriction,restriction=only_right_turn]
I got the list with this patch:
Index: src/uk/me/parabola/mkgmap/reader/osm/RestrictionRelation.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/RestrictionRelation.java
(revision 3116)
+++ src/uk/me/parabola/mkgmap/reader/osm/RestrictionRelation.java
(working copy)
@@ -281,7 +281,7 @@
}
if (result viaWay != null) {
- log.warn(messagePrefix + sorry, 'via' ways are
not supported - ignoring restriction);
+ log.warn(messagePrefix + sorry, 'via' ways are
not supported - ignoring restriction + toTagString());
result = false;
}
return result;
IMO, a role=via way in anything else than restriction=no_u_turn is
likely a mapping error.
The fixes I applied:
2640984: Split the 'via' way, make the part of it oneway. It is an
oneway link between dual oneway lines in a T crossing. After the fix,
you cannot drive against the oneway direction, and the no_left_turn
restriction becomes redundant.
1767298: Remove the restriction. It was redundant, as the other turning
target was tagged with oneway=yes, prohibiting the turn. In fact, all
the ways in the T-shaped crossing were tagged oneway=yes.
67571: Remove one of the ways, make the role=via way the role=from way,
and add a role=via node.
1745548: Make the left-turning lane branch earlier, according to the
lane markings that are visible in Bing imagery. No turn restriction is
needed, because the oneway=yes takes care of it.
BTW, while you are doing this, you could introduce warnings for
redundant turn restriction relations (prohibiting turns against oneway
direction).
Best regards,
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] add-pois-to-areas
Hi Andrzej,
These object aren't tagged the same way, are they? It isn't a simple
case, where information is duplicated. There will be many ways to
interpret and use this informations. For example it could be
advantageous to move tags from area to point.
Right.
AFAICT, the source of the problem is the area-to-POI conversion, which
does not take into account that a more accurate POI (at the boundary
of the area) exists.
Area is an ordered list of poi. Some of them can have tags. You have
to be more precise to define a rule, when area-to-POI function should
be suppressed.
I think that the proper way to do that would be to define an action in
the style language that would somehow input the rules from the style
file. The action would be placed in the 'polygons' file, something like
this:
parking=* {
to_node(parking=* amenity=parking,
{amenity=parking,mkgmap:area-to-poi=yes}
}
This new to_node action would take 2 parameters:
Parameter 1: A condition to match nodes in the polygon perimeter.
The tags from the polygon will be copied to the matching nodes.
Parameter 2: Tags to be added to a generated node, in case no nodes
matched parameter 1.
Let us consider an example where we have an area tagged as
parking=surface but without amenity=parking.
If any perimeter nodes of the area are tagged with parking=something and
amenity=parking, we would copy all tags from the area to these nodes.
If there were no such perimeter nodes, we would create a node in the
middle of the parking=* area, copying the original tags from the area
and adding amenity=parking,mkgmap:area-to-poi=yes.
This is just a quick sketch of the idea. We might want more flexibility
too, such as give a chance to filter out some tags when generating a
POI, or to compare the tags on the perimeter nodes to the tags on the
area.
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] add-pois-to-areas
On Sun, Mar 23, 2014 at 12:18:16PM +1100, Brett Russell wrote: So looks like somewhere on the line the logic in mkgmap was strengthen to pick up what would be a logic error by having POI in polygons. Or at least that is my feelings. Many features can be tagged points (nodes) as well as areas (polygons). The mkgmap option --add-pois-to-areas will introduce POIs for polygons at the center of the polygon (or outside, if the polygon contains both concave and convex parts). IIRC, this will create a POI if there is a covering rule both in the polygons and points files. Examples include amenity=supermarket and amenity=parking. On a related note, IMO we should try to not create POIs for areas for which a similar POI already exists. For example, a parking facility or a building could be tagged both as a point at the entrance, and as an area. How to detect the duplicate POIs? Maybe, flag the auto-generated pois-to-areas nodes in some way, and remove the the auto-generated node if the same points rule(s) would match a boundary node of the polygon. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Turn restrictions with role=via ways
On Sun, Mar 23, 2014 at 09:52:53AM +0100, Gerd Petermann wrote: I am not sure how I should interpret a restriction relation with restriction=only_* and a via way. AFAIK the Garmin format doesn't have such kind of restriction, so we have to translate it into one or more no_* restrictions for the other possible ways. This was rather easy for restrictions with a via node, but how should I do it for via ways? Examples: http://www.openstreetmap.org/relation/67571 This looks like a mapping error (should simply use a 'via' node). http://www.openstreetmap.org/relation/1745548 This one is more tricky. The note on the relation says that there is a lane marking that you cannot cross when turning right from the parking lot. So, you can only continue straight to Mäkelänkatu and not take an immediate left turn to Vääksyntie. It seems that also this one could be corrected in the map data by branching the Vääksyntie exit before the parking lot driveway. In that case, there would be no need for a turn restriction. The real trouble (AFAICT) is no_u_turn with role=via ways. That cannot be fixed by manually simplifying the map data. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Turn restrictions with role=via ways
On Sun, Mar 23, 2014 at 11:16:51AM +0100, Gerd Petermann wrote: I don't care whether the restrictions could be changed in OSM. I just want to make sure that I translate them correctly we writing the img file. IMO, this is on the border of garbage in, garbage out. If there are clear semantics of the role=via ways in turn restrictions that can be easily explained to a human or a computer, sure, they can be supported. It is a matter of finding balance of effort: will the implementation effort be smaller than the effort to map it in a simpler way? It also is a matter of risk: can the more complex translation rule fail the do what I mean semantics that the mapper might have had in mind. In the example of the only_right_turn restriction from the parking lot driveway, we could accidentally introduce an only_straight_on restriction to the main road (prohibiting any left turns). I think that we would need some kind of regression tests for turn restrictions, or routing in general. These examples can be fixed in the map data, and I plan to do so in the next few days. What cannot be fixed in the map data are no_u_turn restrictions on dual-oneways that use role=via ways. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] highway=path only for pedestrians?
Hi Gerd,
AFAIU the rule
highway=path {set highway=footway}
should be removed.
Yes, that sounds correct.
One reason for the current situation could be that you might not want to
route bicycles to a narrow forest path, especially in the autumn when it
is muddy, or in the winter when there is lots of snow. It really depends
on the type of the bicycle and on the weather and road conditions.
Anyway, I guess that mkgmap should not try to be too clever about what
is reasonable. It should only care what is allowed. It is up to the user
to decide whether to follow a routing advice.
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Turn restrictions with role=via ways
Hi Steve, Gerd, On Tue, Mar 18, 2014 at 11:16:53AM +, Steve Ratcliffe wrote: Imagine there are two two roads between A and D; ABCD and AD. You can travel AB and ABC, but there is a turn restriction from C to D. So the 'real' turn restriction is BCD, but they write it as ABCD, perhaps just so that the algorithm doesn't waste time exploring the wrong path if it is at A and needing to get to D. I've no idea how well that relates to what the OSM tags mean. I suspect that in the example that I posted, the mapper wanted to map for the renderer (JOSM in this case). If he used only from,via,to ways in the turn restriction, the no turn allowed traffic sign would show up in the middle of the junction (of two dual-oneway roads). It looks nicer in JOSM if the sign is before the junction, like in the real life. This is of course bogus, just like it is redundant to add a turn restriction that prohibits turning to an oneway road against the oneway direction. If you want to map traffic signs, there is an established tagging scheme for that in Finland. I did not contact the mapper yet to confirm if this is the case. Anyway, the problem is that the U-turn restriction is ABCD (A=from,B=via,C=via,D=to) while BCD (B=from,C=via,D=to) would suffice. AFAIU, other turn restrictions than no_u_turn can always be mapped without via ways (using via nodes). Do you agree? Could we automatically convert such turn restrictions to ones that use via nodes? The translation would do the following: 1. keep the role=to way as is 2. add role=via node at the junction of the role=via way and the role=to way 3. rename the role=via way from step 2 to role=from way 4. discard any other role=via ways, and all role=from ways Does this sound correct to you? Supporting role=via ways for no_u_turn would be a bigger task (requiring knowledge of the Garmin format). Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bogus roundabout warnings
Hi Gerd, Please check if the result of r3114 is okay again. I see only one warning for an older download of finland. Thanks, it is OK. No warnings for Finland with the extract from today. There are plenty of warnings for polygons, but that is a different story, and I will not complain about them until I have fixed most of the data. (I suspect that having a natural=wood,wood=mixed island inside natural=wood,wood=coniferous could trigger a bogus warning.) Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Warnings about hyper-precise multipolygons
Hi Gerd, if you are talking about the messages from ShapeMergeFilter: A possible reason is a self intersecting polygon. The filter assumes that shapes are not self intersecting, but it doesn't test this yet. About a week ago, I got a message that I thought was about merging adjacent (non-overlapping) shapes that carry identical tags. I cannot find such a message now. Here would be two examples of this: http://www.openstreetmap.org/browse/relation/1225936 http://www.openstreetmap.org/browse/relation/1232121 These are hyper-precise multipolygons with two circles. Both the outer ring (actually, the relation) and the inner ring carry the same tag landuse=grass. Only the value of the golf=* attribute differs, but this does not matter to the default style. There used to be two polygons for the inner circle: the role=inner polygon with no tags, and a duplicate polygon with the tags landuse=grass,golf=green. I deleted the duplicate polygon and moved the tags to the role=inner polygon. Tomorrow or the day after, I should see if the mkgmap message is changing. There still are a few hyper-precisely mapped multipolygons, for which mkgmap is emitting messages. It is no problem for me to keep these relations in my ignore list. I usually monitor the output with grep -vf logging.ignore mkgmap.log.0. Many relations that were on my ignore list are no longer generating errors. Either the data has been changed, or the higher precision is helping, or both. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style and underground pipelines
On Thu, Mar 13, 2014 at 10:32:24AM +0100, Gerd Petermann wrote: So yes, if you delete a tag in the lines file, the tag is not visible in the rules of the polygons file. OK. I committed a fix in r3110 that adds additional conditions instead of deleting the man_made tag. I guess that this could lead to closed pipelines becoming polygons on the map. I did not find any such example when I checked the generated map. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Bogus roundabout warnings
With the most recent mkgmap trunk (r3111) I am getting bogus warnings like these: 2014/03/14 22:07:19 WARNING (RouteNode): 63240008.osm.pbf: Roundabout (http://www.openstreetmap.org/browse/way/32502891) forks at http://www.openstreetmap.org/?mlat=63.830711mlon=23.120524zoom=17 2014/03/14 22:07:19 WARNING (RouteNode): 63240008.osm.pbf: Outgoing roundabout flare road (http://www.openstreetmap.org/browse/way/27506601) does not finish at flare? http://www.openstreetmap.org/?mlat=63.905483mlon=24.516046zoom=17 2014/03/14 22:07:19 WARNING (RouteNode): 63240008.osm.pbf: Roundabout (http://www.openstreetmap.org/browse/way/27506649) forks at http://www.openstreetmap.org/?mlat=63.905981mlon=24.514913zoom=17 I suspect that these are being triggered when there are nodes very close to each other, and they are being merged. I do not remember seeing these warnings yesterday, with r3110. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style and underground pipelines
On Thu, Mar 13, 2014 at 09:46:26AM +0100, chris66 wrote:
Something like:
man_made=* location=underground {delete man_made}
in front of the main rule.
Yes, and maybe others, such as:
man_made=* tunnel=yes {delete man_made}
But, there could be a caveat. What is the scope of delete? If a
polygon rule uses delete, will the tag be visible in a line rule? Or
vice versa?
By the way, the man_made=* rule at the bottom could accidentally catch
some man_made that were skipped because of area=yes earlier. I think
that we should do one of:
man_made=* area=yes {delete man_made}
or add area!=yes to the cable/pipe rule.
If the delete action could interfere with rules in other files, I guess
we should change the bottom rule from
man_made=cable|(man_made=* man_made ~ '.*pipe.*')
to something like this:
(man_made=cable|(man_made=* man_made ~ '.*pipe.*')) area!=yes
tunnel!=yes location!=underground
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bogus anti-island warnings for tiny natural=coastline
On Tue, Mar 11, 2014 at 08:33:34AM +0100, Gerd Petermann wrote: I guess we can change that, but I'd first like to finish the NOD127 branch. Thanks, now I only see very small shape warnings, with no OSM tags. The tags might be useful for collecting some statistics, but little else. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Turn restrictions with role=via ways
Now, with all these routing improvements, I wonder if it would be possible to extend our support for turn restrictions. Some mapper seems to prefer via ways to via nodes in this crossing: http://www.openstreetmap.org/way/30692839 This 2-node way is a role=via member of a no_u_turn restriction that has 4 ways as members: from,via,via,to. It is also a role=via member of a no_left_turn restriction. The no_u_turn restriction could have been mapped with three ways as from,via,to and the no_left_turn could have been mapped with having this way as role=from, and a node as role=via. Even if I changed the map like that, mkgmap would still ignore the no_u_turn, because the role=via member would be a way. So, I wonder if we could start supporting this style of mapping? There are lots of dual carriageways in city areas where such turn restrictions are common, at least for no_u_turn. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Bogus anti-island warnings for tiny natural=coastline
Hi, I am getting bogus warnings like this: 2014/03/10 12:31:16 WARNING (SeaGenerator): 63240002.osm.pbf: Converting anti-island starting at http://www.openstreetmap.org/?mlat=60.217808mlon=25.309372zoom=17 into an island as it is surrounded by water This tiny natural=coastline polygon http://www.openstreetmap.org/way/241289746 represents a tiny islet in the Baltic sea. It has land on the left. I would prefer to see a very small shape warning like this instead, so that I can ignore it: 2014/03/10 12:31:17 WARNING (ShapeMergeFilter): 63240003.osm.pbf: very small shape near http://www.openstreetmap.org/?mlat=60.312562mlon=26.259787zoom=17 signed area in high prec map units: 1188 It would be nice if this very small shape warning echoed the tags or even the OSM ID of the shape. (Of course, only if the information is easily available; it might have already been thrown out during the translation.) Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style and underground pipelines
Hi Gerd,
is it intended that these ways are placed in the map?
sample:
http://www.openstreetmap.org/way/60575011
man_made=pipeline
type=water
location=underground
This rule in lines fires:
man_made=cable|(man_made=* man_made ~ '.*pipe.*')
{name '${name} (${operator})' | '${name}' | '${operator}' }
[0x28 resolution 23]
I wrote this rule with visible features in mind, such as oil or gas
pipelines in rural areas. In well-mapped urban areas, this can cause
unnecessary clutter, just like subways and tunnels with access=private,
which are being omitted by the default style.
Maybe there should be a way to limit the visibility of some objects
based on the map density or nearby map features. If a cycleway or
highway is parallel to a pipeline, then the pipeline should be hidden
except maybe in resolution=24. Likewise, if a cycleway is parallel to a
highway, it should be hidden at lower zoom levels. If there are two
antiparallel oneways for a highway=*, only one should be generated at
lower zoom levels.
Best regards,
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] type=multipolygon relations
Hi WanMil, Gerd, On Sun, Jan 19, 2014 at 10:47:15AM -0800, GerdP wrote: Hi WanMil, I think your example is not valid. One rule in that wiki says: If an endpoint is shared by more than two unclosed ways, it's ill formed and a closed polygon can't be reconstructed unambiguously. I think both end points of 3 are shared by three unclosed ways. I agree with Gerd that the example is not valid: 11 11 1 2223 1 1 2 3 4 1 1 2 3 4 1 1 2223 1 11 11 MP: tags natural=forest Way 1: role=outer Way 2: role=inner, natrual=scrub Way 3: role=inner, natrual=scrub Way 4: role=inner, natrual=scrub I think that this should be mapped with 3 multipolygon relations: MP1: natural=forest: role=outer: way1, role=inner: way2, way4 MP2: natural=scrub: role=outer: way2, way3 MP3: natural=scrub: role=outer: way3, way4 If you really meant natural=scrub for both 2+3 and 3+4, I think that this could be simplified by removing way 3 and merging ways 2 and 4. The example would make more sense if MP3 is tagged as natural=water, for instance. In my opinion, mkgmap should issue a warning for the duplicate way 3 for your example. It does not seem much different from a situation where two inner polygons are touching or intersecting each other. I think that the unambiguous way of mapping is to draw a bigger hole around the adjacent areas, like MP1 in the above example does. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] type=multipolygon relations
On Sat, Jan 18, 2014 at 04:30:34PM +0100, Gerd Petermann wrote: I wonder why we don't remove duplicate entries when we process the members of mp relations. Is there any possible constellation where this would cause trouble? I cannot think of any. It should also not make any sense for the same way to be in different roles in a multipolygon relation. (In a route relation, you could have the same way twice, in role=forward and role=backward. You might even have a way multiple times, if the route is visiting points A, B, A, C, A.) The JOSM relation editor is highlighting duplicate relation members. I think that it would be good to issue a log message for the duplicate multipolygon members, so that the data can be corrected (simplified). Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] type=multipolygon relations
On Sat, Jan 18, 2014 at 10:58:58PM +0100, Minko wrote: Good luck for correcting them, there are tons of those faulty mp's all over the place in NL's ;-) I wouldnt spend too much time for this, better ignore it. I have found the existing multipolygon and coastline warnings very useful. The check for duplicate member ID in a multipolygon relation is cheap and has to be done anyway. There is really no good reason not to warn about them. By default, the log output is not enabled. You have to specify -Dlog.config=logging.properties in order to enable the diagnostic. Even after doing so, you could filter out these particular messages either by grep -vf or by configuring the logging.properties file appropriately. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Question regarding duplicated shapes
On Sun, Jan 12, 2014 at 03:46:30PM +0100, Gerd Petermann wrote: while debugging the shape merger I found many duplicated shapes in Finland, and I am not sure how mkgmap should handle them. Oh, the Corine import by teollisuus (industry in Finnish) is hopeless IMO. :( It is based on very inaccurate data, and the converter is generating duplicate ways and improperly tagged multipolygon relations, like in your example. Instead of defining the area-style tags on the multipolygon relation itself, this import added the tags to all relation members (both role=inner and role=outer). JOSM at least used to display this as intended, IIRC. Whenever I have fixed some multipolygon error in Finland, I have tried to remove the duplicate shapes, and to move the area-style tags to the multipolygon relation. It is sometimes tricky if someone has already tried to edit the imported data. Example: http://www.openstreetmap.org/way/105723026 is tagged landuse=farm and is the role=inner member of multipolygon relation http://www.openstreetmap.org/relation/1504949 which has only one role=outer way which also is tagged landuse=farm. Way http://www.openstreetmap.org/way/105719041 is a copy of way 105723026, but with reverse order of points. It is tagged natural=scrub Yes, this is exactly what I have seen many times. FWIW, I do not think that mkgmap should spend too much effort in supporting this broken and redundant way of mapping multipolygons. The Corine data is very low-resolution, basically useless. Now that we finally got the license stuff sorted out at http://www.openstreetmap.org/copyright the import from the National Land Survey database is only a matter of writing and configuring a converter, and manually resolving conflicts with existing data. In this process, the Corine landuse imports will probably be deleted. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service
On Sun, Jan 05, 2014 at 08:25:12AM -0800, GerdP wrote: The question is: If you get a list of oneway road (parts) which create routing islands, is it really the only conclusion that these oneways are wrong? I cannot think of any other conclusion in the practice. See below for a somewhat artificial example. Before I left the academic world 10 years ago, I implemented Tarjan's algorithm for strongly connected components in a model checker tool. It was applied to the graph of reachable states (reachability graph) of the modelled system, which would typically be a high-level model of a distributed system or protocol. A desired property of any distributed algorithm is that its state diagram is strongly connected, that is, you can get from any valid state to any other valid state by performing a number of possible actions. When the reachability graph of a distributed system is not strongly connected, it usually means that one or more actors (processes, threads, whatever) are stuck. The system as a whole might not be in a deadlock, if some processes can keep doing something. There is a class of distributed algorithms called self-stabilizing algorithms. They have the additional property that you can get from any state (including invalid states) to the valid states. In the reachability graph of this kind of a distributed algorithm you would have a very large number of initial states (all possible states of the distributed system), and there would a strongly connected component of the valid states. Now, let me get back to the OSM domain. I guess we could think of a restricted area that only defines oneway exits to the public road network, but the entry roads are well-kept secrets (maybe enforced by law). If the road network within the restricted area is mapped, then it would form its own strongly connected component from which you can get to the strongly connected component of the public road network, but not vice versa. (By definition, the graph of strongly connected components is acyclic.) Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service
On Mon, Jan 06, 2014 at 08:02:57PM +0100, Gerd Petermann wrote: before I retired I worked for a company that develops tools around the (job) scheduling tools in IT centers. One typilcal problem in this area is a loop of dependencies (job a depends on b, b on c, c on d, .. , x on y; y on b) which may result in deadlocks. In such a loop it is not possible to say which dependency is wrong, you can only list the elements of the loop and an expert has to say where the loop has to be split. Still our customers asked for a tool to show THE wrong depency. Your email reminded me a bit on this ;-) Yeah. :) By the way, I was wondering how you have so much expertise and energy to work on this. (I cannot code anything big on spare time, because my brain needs a break after working on complex coding problems at the day job.) Now I got the answer. Nice to see that active OSM development is not only for students and young people. Your example is very similar to using a model checker. For a safety property violation (say, an assertion on the global state, or a check for a system-wide deadlock) the model checker would give you a (shortest) path of actions leading from the start to the error. For a liveness property violation, the counterexample would be a path to a non-progressing loop, plus the loop itself. In the OSM case, maybe it is a way that is missing and not a wrong oneway tag. I think someone has to visit the place to find out. Right. The global check could at most say something might be wrong, and human intervention would be required. In my experience, even for local errors it is useful to look at the surroundings, to see if the JOSM Validator reports any errors nearby. Another question is what we can do with such wrong data in the map produced by mkgmap. One option could be to emit a warning, saying that we are going to strip oneway=* from way X in order to avoid a potential problem. This could be enabled by --report-dead-ends=3 if we want this to be optional. Also, what would the Garmin routing algorithms (different versions of Mapsource etc.) do with such data? For example, can the routing get stuck if a P-shaped oneway (with no junctions to other roads, besides from the foot of the P) is the closest way to the starting point or the destination point? Does it matter if the P is split into foot and loop parts in the Garmin map? Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service
Hi Gerd, With the newer patch and the data from last night, the new check did not report any issues that were missed by the old check. The new check failed to report these ways that were flagged by the old check in trunk: 200035193,220389737,25455464,42191422,53197410,131648853,50118184 Strange, after sorting I don't see a single difference for finland. I am using manually assigned tiles. My scripts are at http://www.polkupyoraily.net/osm/ with the most important ones being http://www.polkupyoraily.net/osm/files/areas.list http://www.polkupyoraily.net/osm/files/osm2img.sh Please post one of your tiles (the input file) with a difference. There are two tiles with one message (nowhere near the tile borders): 63240004: 2822016,956256 to 2916352,1172416 # : 60.553894,20.519027 to 62.578125,25.157318 2014/01/03 23:34:09 WARNING (RouteNode): 63240004.osm.pbf: Oneway road (http://www.openstreetmap.org/browse/way/131648853) goes nowhere at http://www.openstreetmap.org/?mlat=61.498772mlon=23.777456zoom=17 63240010: 3014656,040 to 3067072,1409024 # : 64.687500,23.840332 to 65.812225,30.234375 2014/01/03 23:35:00 WARNING (RouteNode): 63240010.osm.pbf: Oneway road (http://www.openstreetmap.org/browse/way/50118184) goes nowhere at http://www.openstreetmap.org/?mlat=65.011645mlon=25.467852zoom=17 Most messages are for this tile: 63240002: 2784459,1093376 to 2822016,1195648 # : 59.748008,23.461304 to 60.553894,25.655823 2014/01/03 23:34:24 WARNING (RouteNode): 63240002.osm.pbf: Oneway road (http://www.openstreetmap.org/browse/way/25455464) goes nowhere at http://www.openstreetmap.org/?mlat=60.172919mlon=24.947340zoom=17 2014/01/03 23:34:25 WARNING (RouteNode): 63240002.osm.pbf: Oneway road (http://www.openstreetmap.org/browse/way/42191422) goes nowhere at http://www.openstreetmap.org/?mlat=60.212344mlon=25.084937zoom=17 2014/01/03 23:34:25 WARNING (RouteNode): 63240002.osm.pbf: Oneway road (http://www.openstreetmap.org/browse/way/53197410) goes nowhere at http://www.openstreetmap.org/?mlat=60.212325mlon=25.084907zoom=17 2014/01/03 23:34:25 WARNING (RouteNode): 63240002.osm.pbf: Oneway road (http://www.openstreetmap.org/browse/way/200035193) goes nowhere at http://www.openstreetmap.org/?mlat=60.203610mlon=24.659707zoom=17 2014/01/03 23:34:25 WARNING (RouteNode): 63240002.osm.pbf: Oneway road (http://www.openstreetmap.org/browse/way/220389737) goes nowhere at http://www.openstreetmap.org/?mlat=60.176588mlon=24.807431zoom=17 AFAICT, none of these are near the tile boundaries. The min/max lat is between 60.17 and 60.22 (well within 59.748..60.553) and the min/max lon is between 24.65 and 25.085 (inside 23.46..25.65). Attached is also the style that I use to test the dead-end-check. I am using the default style. That could explain the difference, because the default style is omitting some tunnels from the map. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service
On Sat, Jan 04, 2014 at 02:05:11PM +0100, Gerd Petermann wrote: You don't use parameter --x-no-mergeroads in your script as I recommended. Ah, sorry, I forgot that piece of your advice :( But, I think that I will live with this for now. I mainly use mkgmap for fixing map errors; I retired my Garmin unit about 2 years ago when its USB interface died, preventing me to use it for recording GPS traces. I replaced it with a small Android phone and OsmAnd. It works, in most aspects better and in some aspects worse than the Edge 705. The merge algo doesn't look at the tag mkgmap:dead-end-check, so it may merge a way with that tag into a way without it. I did not change that in RoadMerger because we want to replace the old code. I think it looks good, I just have to add code for the p-shaped oneways. Thanks, this sounds good to me. The main thing is that we have an explanation for the discrepancies. By the way: Why do you use --overlap=1 for splitter? Is the keep-complete option not working for you? I started using it in November 2011 because of errors for some natural=water multipolygons near a tile border. I see that the keep-complete option was introduced (or changed) in splitter over a year later. Thanks for the hint, I will start using that in my script. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service
On Sat, Jan 04, 2014 at 09:43:32PM +0200, Marko Mäkelä wrote: On Sat, Jan 04, 2014 at 02:05:11PM +0100, Gerd Petermann wrote: You don't use parameter --x-no-mergeroads in your script as I recommended. Ah, sorry, I forgot that piece of your advice :( OK, now I think I understand this (without trying that option yet; I think that merging roads is generally a good idea, even with this bug being present). Many of the warnings that I get are for situations like this: --F where is the oneway that I get a warning for, and is another oneway that ends in a fixme=continue or similar. I guess that the two ways get merged, but tags are not being merged, or the flag to suppress dead-end checks gets discarded. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service
Hi Gerd, 3) The new check did not recognize P-shaped oneways as self-connecting. This was not a bug in the new check, but a bug in the old check! I agree that by definition, looped ways cannot be dead ends. For the purpose of detecting dead ends, we could ignore non-branching loops formed by a sequence of ways. Actually, it does not matter if the non-branching loops are oneway! If there is no non-looped way connected to both ends of the foot of the P, then the foot of the P forms a dead-end oneway. That is, a P-shaped oneway should be treated just like an I-shaped oneway that is obtained by removing the looped part. Maybe you could use this idea to improve dead-end checks? Note that a roundabout does not count as a non-branching loop, unless it is connected to a single oneway flare road only. Attached is a new version of the patch. Thanks, I will try it later for today's data. I already ran trunk and the previous patch on the data. I think this is okay as long as you see the warning for way Y. Me too, it is OK to be silent about some part of an error scenario, as long as some of the connected ways get flagged. I usually download a region around the problematic spot in order to figure out what the intention is and how it should be fixed. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service
On Fri, Jan 03, 2014 at 03:29:22PM +0100, Gerd Petermann wrote: okay, thinking again about endlessly traveling in a loop I guess it is a special form of a deadend when there is no other exit ;-) Right, that was what I had in mind. Generally, if the routing graph is not strongly connected (it is not forming a single strongly connected component) it should be a sign of invalid oneways. When there are no oneway=* attributes, the routing graph will trivially be strongly connected (you can get from anywhere to anywhere, because you can traverse the edges in both directions). A special case is when there are multiple routing islands even when ignoring the oneway=* attributes. Within a map tile, we can legitimately have multiple routing islands, for example if no ferry connection has been mapped to an island, or when some ways in the tile are connected by ways in adjacent tile(s). We should only complain when the introduction of oneway=yes splits a routing island. There is an efficient algorithm for computing the strongly connected components of a directed graph: http://en.wikipedia.org/wiki/Tarjan%27s_strongly_connected_components_algorithm Perhaps we could invoke the algorithm in two passes: (1) on the undirected graph of roads (hard-wiring oneway=no) Each strongly connected component (SCC) would be a routing island. (2) for each SCC from step 1 that contains oneway=yes attributes: If the SCC would be split, list the oneway=yes ways (or some of them). Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service
On Fri, Jan 03, 2014 at 04:05:20PM +0200, Marko Mäkelä wrote: Thanks, I will try it later for today's data. I already ran trunk and the previous patch on the data. Compared to the previous patch, the new patch is omitting warnings for three P-shaped oneways: 23152992,64148077,167346021. (Also the old check in trunk missed these.) I fixed all these errors by removing the oneway=yes from the foot of the P. With the newer patch and the data from last night, the new check did not report any issues that were missed by the old check. The new check failed to report these ways that were flagged by the old check in trunk: 200035193,220389737,25455464,42191422,53197410,131648853,50118184 Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service
Hi Gerd, okay, I'll have a look at it during the next days. Thanks! BTW, the diagnostics is not completely useless as it is now; it does include labels, which (when present) will identify the ways. But, in addition to normally unnamed highway=service, there could be some ways that are accidentally left unnamed, such as when splitting a way to a dual carriageway near a junction (Y-shaped). Then, both oneway arms of the Y could accidentally point to the same direction, which would trigger a warning. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service
Hi Gerd, I figured out that it would be nice to display all tags of the dead-end oneway, like we do in MultiPolygonRelation, so that my mkgmap wrapper script could filter out any oneway warnings for highway=service. I am not sure if I got that right. If you want to suppress the dead-end-check for all ways with specific tags, you can do it in the style (add the tag mkgmap:dead-end-check=false to the way) I do not want to suppress dead-end-checks altogether. I do it on a case-by-case basis, either by adding fixme=continue to the endpoint (this will set mkgmap:dead-end-check=false on the way; I wrote the code to do that), or by filtering out messages. Here is a slightly different example: ... Motorway exit 67 (http://www.openstreetmap.org/?mlat=60.47712mlon=26.27170zoom=17) has no motorway! This is for node 1909615887. The message fails to mention the tags of the attached way 181498435 (highway=construction, construction=motorway, ...). I have a file that I pass to grep -vf for suppressing known warnings. I would not want to add a suppression for this message as it is now, because it would remain suppressed after the construction is completed and the way gets tagged highway=motorway. If my suppression regexp were something like Motorway exit 67 .*mlat=60\.47712mlon=26\.27170.*highway=construction then it would no longer suppress the warning if the way is changed to highway=motorway and some map editor breaks something. (Even better than coordinates would be the ID of the highway=motorway_exit node.) Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH] Do not create RestrictionRelation for unspecified restriction
There are a few restriction relations for no through route mapped in
Finland. These are a bit ambiguous, because it looks like there are
multiple possible routes, all of which are banned. These relations are
tagged with type=restriction, but not with any restriction=*.
For mkgmap, the issue is that multiple warnings get emitted for the
single relation. The attached patch would emit just one warning, for the
restriction=* being missing. OK to commit?
(Side note: I think that it could be better if there was a factory
method that created the RestrictionRelation if it is supported. It seems
to be a waste of memory to create a RestrictionRelation object that we
do not support, for example when there are via ways instead of via
nodes.)
While working on this, I was wondering why we set rel=null if turn
restrictions are being ignored. I think that the relation should be
collected, just like any relation that does not have any magic meaning,
so that any style rules could process the relation. I did not touch that
part of the code.
Best regards,
Marko
Index: src/uk/me/parabola/mkgmap/reader/osm/ElementSaver.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/ElementSaver.java (revision 2916)
+++ src/uk/me/parabola/mkgmap/reader/osm/ElementSaver.java (working copy)
@@ -144,6 +144,8 @@
} else if(restriction.equals(type)) {
if (ignoreTurnRestrictions)
rel = null;
+else if (rel.getTag(restriction) == null)
+ log.warn(ignoring unspecified restriction + rel.toBrowseURL());
else
rel = new RestrictionRelation(rel);
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service
On Thu, Jan 02, 2014 at 04:27:23PM +0100, Gerd Petermann wrote: attached is a patch for the high-prec-coord branch to perform the dead-end-check in StyledConverter. I did not remove the original code, so both tests are performed now. I think this helps to find differences. Thanks! This looks verbose enough for my taste: 2014/01/02 19:42:16 WARNING (StyledConverter): 63240004.osm.pbf: Oneway road 55835321 with tags [oneway=yes,mkgmap:street=Pentinkaarre,name=Pentinkaarre,mkgmap:label:1=Pentinkaarre,highway=living_street,surface=paved] goes to nowhere at http://www.openstreetmap.org/?mlat=62.262185mlon=24.710546zoom=17 Maybe you could filter out the generated mkgmap:* tags, but I am OK with it. I guess that the logging output is too verbose to be read directly by a human anyway (without any searching or filtering, that is). This way is (was) P-shaped. The oneway=yes would be OK for the D-shaped loop of the P, but not for the 'foot'. I fixed this particular error, but left others there, so that we can do more cross-checking with subsequent patches. I got 23 Oneway warnings with your branch+patch, and 13 with trunk. The differences are as follows, after filtering out timestamps and sorting both outputs: * Different coordinates for the 13 old messages (as expected; this is thanks to the higher precision) * 'Extra' warning for the ways: 55835321 23152992 64148077 167346021 * 'Missing' warning for the ways: 200035193 220389737 25455464 42191422 53197410 131648853 50118184 The 'missing' warnings could be because the ways are connected to other ways for which map is not being generated, such as a highway=service,oneway=yes leading to a highway=service,oneway=yes,tunnel=yes,... that is omitted from the map. IMO the 'missing' warnings should be emitted; we should be checking that the generated map makes sense. Please note that both checks will not recognize restriction relations which prohibit to enter or leave a oneway. Right. Ignorance is bliss. :) A related note with oneways is that some mappers seem to generate redundant turn restrictions for oneways. For example, they would add a relation that prevents turning against the oneway from a motorway_link to the motorway lane. I wonder if we should emit warnings for such redundant relations? Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Do not create RestrictionRelation for unspecified restriction
Gerd, thanks for the review. I will wait a bit before committing to trunk, in case someone has another opinion. I think it is ok to ignore the restriction, because we have no other code to interpret it. My point is that there could be a style rule to interpret the type=restriction relation. (Maybe someone wants to create a map layer containing all ways or nodes participating in restrictions.) So, it would seem like a bug to silently discard the type=restriction relation if the built-in processing of it is disabled by a command-line option. But, I guess that we can leave it as is for now. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service
On Thu, Jan 02, 2014 at 11:19:06AM -0800, GerdP wrote: Hi Marko, please check: Marko Mäkelä wrote * Different coordinates for the 13 old messages (as expected; this is thanks to the higher precision) I don't yet see a reason for different coordinates. Did you really compare the output one program execution? Or did you use a different program for the old messages? I did 2 comparisons with the output from 2 runs: With mkgmap/trunk r2916 With mkgmap/branches/high-prec-coord r2930 and your patch First, I compared the output of trunk to the output of branch, using the finland.osm.pbf from Geofabrik dated today, 02:16 UTC. There were 2 differences: (a) Variation of the coordinates in the 13 old-style messages (b) Addition of 10 new-style messages This was to be expected. What was not expected was the difference 13 vs. 10. To diagnose it, I performed another comparison within the output of the patched branch. Many of the old messages had direct counterparts in the new messages, but some new messages for old messages were missing, and some were extra (only new message for the way, no old one). In my previous message, I listed the OSM way IDs for both cases. I fixed one error (for one extra new message) in the OSM database, but I left the others intact, so that we will have some errors in the next finland.osm.pbf to check against. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service
On Mon, Dec 30, 2013 at 01:25:34PM -0800, GerdP wrote: I think the dead-end test can be done in StyledConverter. The test is quite similar to the one that is done in findUnconnectedRoads(). This sounds reasonable to me. The sooner the validation checks are done, the better, because we will have a more direct connection to the style language and the OSM data. This is the direction that mkgmap has been following recently, thanks to you and WanMil. Unfortunately I cannot spend much time in coding (I get too much of it at my day job). I can volunteer to test patches and do some analysis on the output. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service
There are some dead-end highway=service,oneway=yes that trigger dead-end-check warnings in mkgmap RouteNode.java. To allow suppressing most of the warnings, years ago I added a check that suppresses the warning if either end node of the way is tagged with fixme=* or FIXME=*, such as fixme=continue. This is not always applicable, for example when the oneway highway=service is leading to a tunnel, which is omitted from the map in order to avoid clutter (such as ways for underground parking) in city areas. I figured out that it would be nice to display all tags of the dead-end oneway, like we do in MultiPolygonRelation, so that my mkgmap wrapper script could filter out any oneway warnings for highway=service. Unfortunately, the RoadDef is in the Garmin domain, and there is no RoadDef.toTagString() method. Any ideas how to improve the diagnostics? Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search confused by place=* with name,ref
On Wed, Dec 25, 2013 at 12:05:59AM +0100, Henning Scholland wrote: if you find something like Xi:xii Kyttälä, FIN in a name-tag, then this shoulod be wrong for a town. The name of the town would be Kyttälä, or am I wrong? The tags of node 2129650976 are: ref=XI;XII source=Bing place=suburb name=Kyttälä I think that this is an error of mkgmap instead of an error in the source data. The place=* ref is not something that you would normally see anywhere; therefore it should not be included in the mkgmap translated label. I do not see an error in the source data, other than the ref of the suburb not being fully qualified (it should start with NUTS and LAU references that qualify the city of Tampere). BTW, the place=city of Tampere (node 30969480) is lacking ref. It is in role admin_centre of two boundaries (admin_level 8 for the city and 6 for the province of Pirkanmaa). The latter relation does have ref=FI197, but there is no ref for the city relation. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search confused by place=* with name,ref
On Wed, Dec 25, 2013 at 12:32:17PM +0100, Henning Scholland wrote: ok so I misunderstood you. You wrote something of filtering osm.pbf with osmosis and afterwards there were elemets with name Xi:xii Kyttälä, FIN. The only thing I did with Osmosis was troubleshooting. I filtered all place=* nodes with Osmosis so that I was able to load the relevant part of finland.osm.pbf to JOSM to see what is going on. The map is generated straight from finland.osm.pbf with splitter and mkgmap using the default style. The only 'hack' in my osm2img.sh is the assignment of tile borders in a way that avoids 'drying' the Baltic sea. (For the tile near the twin city Haparanda/Torneå/Tornio on the Swedish-Finnish border, I am passing --generate-sea=multipolygon,extend-sea-sectors. Other tiles use plain --generate-sea=multipolygon.) But as you explained now, mkgmap creates this name. So I agree with you: Your given name shouldn't be generated by mkgmap. Thanks! I guess I should have been more explicit. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search confused by place=* with name,ref
On Wed, Dec 25, 2013 at 02:02:00PM +0100, Andrzej Popowski wrote:
using ref tag for name is programmed in default style, see file
inc\name. I think you can correct it in file points, moving line
include inc\name after definitions for tag place.
Right, this would fix the problem for place=*. But, before fixing that,
I would like to ensure that the boundary=administrative relations are
working in a similar way.
I guess that the inc/names is not such a good idea for other than
commercial POIs (shops, fuel stations, anything with a fee). The ref=*
does make sense for roads, but operator=* (such as the maintenance
operator) or brand=* probably do not. However, there is no problem for
roads in the default style, because the 'lines' file is not referring to
inc/names.
In Finland, street names are supposed to be unique within a municipality
or city (admin_level=8). So, for the address index it would be best to
only use the 'city' name from the boundary relations, and to ignore any
suburbs or city parts. If I now search for Vantaa, I will find some
streets located in the city. Other streets would have to be sought in
city parts such as Vantaanportti and Vantaanlaakso. Hardly anybody would
know all the city parts.
While the suburb or city part borders are useless for address search,
they could still be interesting on the map display, because the Finnish
'cities' typically contain many 'towns' separated by large areas of
nearly uninhabited farmland or forest.
Another issue is that the boundary naming rule in
styles/default/relations does not seem to have any effect any more. The
boundary lines near my home are only listing one of the relation
'owners' instead of showing all names that were added to
mkgmap:boundary_name. The lines used to list all municipal or provincial
borders (e.g., Kerava/Sipoo/Helsingin seutukunta/Itä-Uusimaa/whatnot).
Now only one name is being shown at random. On the Finnish/Russian
border, that name is 'Suomi' (Finland in Finnish) for a few sections of
the border, but many sections have some transliterated label from some
Russian boundary=administrative relation.
I wonder if it would be possible to define up to 4 labels for an
administrative border, like for streets. If it is possible to show only
one label for a border, it should be that of the municipality ('city'),
not smaller (suburb or village) or bigger (province, state or country,
if the municipality happens to be on a provincial border).
I think that it could make sense to define separate lines for interstate
or international borders (so that the major border could be overlapped
with a lesser border that belongs to the municipality or province
bounded by the same line).
Best regards,
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search confused by place=* with name,ref
On Tue, Dec 24, 2013 at 09:44:15AM +0100, Henning Scholland wrote: for me it sounds like a bug in OSM, which should be fixed. What is the bug in OSM data? That the ref=* should be attached to the boundary=administrative instead of the place=town? I guess I should try with precompiled bounds. The 3-digit refs are the official reference codes for municipalities. I I guess that the ref could be longer, consisting of proper NUTS and LAU prefixes. For example, the ref=10 for Tykkimäki (a part of Kouvola) could be some kind of a suburb or village code. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Address search confused by place=* with name,ref
I had not tested the map on my Garmin Edge 705 for a long time, so I do not know how long ago this got changed. Now I tested with a recent mkgmap trunk. It could be the revision right before the mergeroads branch was merged. After the merge, I got some strange error and no *.img files. In the address search, I have 3 regions to choose from: Finland, Åland islands, or Russian Federation. When I select Finland, I see 3 places at the top of the list: 10 Tykkimäki, 611 Pornainen and 732 Salla. To see where these come from, I loaded the output of the following to JOSM: osmosis --rb finland.osm.pbf --tf reject-relations --tf reject-ways \ --tf accept-nodes 'place=*' --wx finland-place.osm It turns out that there are a few more place=* nodes with nameref set, but the rest seem to use Roman numerals or be outside of my map tiles (near the country border). Searching for X finds Xi:xii Kyttälä, FIN, which is ref=XI;XII. Searching for I finds a few more suburbs in Tampere. The real issue is that searching for Tykkimäki or any prefix for it will not find the 10 Tykkimäki. How could this be fixed (index the entry with both $ref $name and $name)? Could the ref=* of a place be omitted from the address search? I suppose that I would get slightly different results, for ref=* in boundary=administrative relations, if I used something else than --location-autofill=nearest. I think that many boundary=administrative relations would carry the ref= of the municipality or suburb. These ref numbers are really nerdy stuff, you can at most find them on some government forms, never in street signs. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Bogus anti-island warnings for tiny natural=coastline polygons
On Tue, Dec 17, 2013 at 12:18:23PM -0800, GerdP wrote: @Marko: Please check if the converting anti-island messages are gone now. There are 20 of them for Finland after applying my filter. There could also be valid warnings, because I have been ignoring these errors and not adding them to my filter either. I checked one example: 2013/12/18 16:28:01 WARNING (SeaGenerator): 63240002.osm.pbf: Converting anti-island starting at http://www.openstreetmap.org/?mlat=60.20405mlon=25.49942zoom=17 into an island as it is surrounded by water It looks like this is referring to the 1.5m wide islet or rock http://www.openstreetmap.org/way/242824968 which is a closed polygon, with land on the left. I think that the proper action would be to shrink this to a single point and then discard it, because it would be a polygon with zero area. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bogus anti-island warnings for tiny natural=coastline polygons
On Wed, Dec 18, 2013 at 04:36:09PM +0100, Gerd Petermann wrote: thanks for the feedback. Did you use r2888 or later together with the patch? Yes, I updated to trunk -r2894 right before applying the patch. No other patches were applied. I am not very familiar with the SeaGenerator algo, but I think this message is produced when incomplete data is processed and mkgmap once decided that way 242824968 encloses sea and later detects that it must be an island. Could be. In any case, it would be nice to get rid of these bogus warnings, so that the real coastline errors can be fixed. Yes, the errors could be checked with the JOSM Validator, which implements some checks. AFAIU, the neither the JOSM nor mkgmap checks are subsets of each other (you need to run both to get all checks). Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Questions about carpool handling
On Mon, Dec 09, 2013 at 09:20:41AM +0100, Minko wrote:
mkgmap:carpool=yes { mkgmap:carpool=no }
[snip]
Error in style: Error: (lines:204): Unrecognised command 'mkgmap:carpool'
I guess you did not notice that WanMil forgot the set. add would not
work here, because the tag already exists and you want to override it.
Best regards,
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] One node - two index entries?
On Sat, Nov 09, 2013 at 02:36:58PM +0100, Bernhard Hiller wrote: Hence my question is: is it possible to get one node into the index twice in different categories? FWIW, the Garmin Edge 705 does this for some POI types by itself. For example, a Truck stop or Convenience store will show up in 2 menus. These are in the default style: amenity=fuel fuel:HGV_diesel=yes [ 0x2f16 resolution 23] amenity=fuel shop=convenience [ 0x2e06 resolution 24] I tried following rules: tourism=hotel amenty!=* [...] tourism=hotel amenty=* [...] If you misspelled the amenity, then it obviously cannot work, unless you also misspell it in the data. :) I do not see why it should not work (generate 2 Garmin POIs), but I have not used 'continue' much. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch v1] avoid wrong bearing results
On Thu, Oct 31, 2013 at 10:44:31PM +0100, Gerd Petermann wrote: the patch (this v1) is only meant to solve routing problems caused by rounding I don't think that it has an influence on SeaGenerator. Right, I was too optimistic, hoping that this would fix the bogus warnings in SeaGenerator too. The patch (or some other change since r2795) did make 2 of 4 warnings for roundabout flare roads go away. Only the following remained: 2013/10/31 21:17:17 WARNING (StyledConverter): 63240002.osm.pbf: Roundabout segment 35062431 direction looks wrong (see http://www.openstreetmap.org/?mlat=60.23825mlon=24.88777zoom=17) 2013/10/31 21:17:18 WARNING (StyledConverter): 63240002.osm.pbf: Roundabout segment 34151581 direction looks wrong (see http://www.openstreetmap.org/?mlat=60.23242mlon=24.95879zoom=17) 2013/10/31 21:17:37 WARNING (RouteNode): 63240005.osm.pbf: Outgoing roundabout flare road (4;9;13;23 Vaajakoskentie, http://www.openstreetmap.org/browse/way/221616945) points in wrong direction? http://www.openstreetmap.org/?mlat=62.24637mlon=25.87302zoom=17 Both roundabout segments are in micro-mapped roundabouts that have been split because of route relations. I reverted your patch and reran with today's dump. I got again the usual 5 roundabout warnings (2 more about flare roads) than the above. So, your patch is making a positive difference there. Do you have a reason for not using precompiled sea? Yes. I mainly use mkgmap as a validator, and I am routinely fixing errors in finland.osm.pbf. The sea polygons are not severely broken that often, it is usually just anti-islands. Only about once per month I have to fire up JOSM with an Osmosis-made extract of natural=coastline to see what is wrong. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch v1] avoid wrong bearing results
On Thu, Oct 31, 2013 at 10:08:53AM -0700, GerdP wrote: a few weeks ago I suggested that we might need higher precision in the Coord class. Attached patch is a quick hack to implement this. If I got it right, this may allow to remove a lot of code that tries to correct what the rounding had done wrong. For the beginning, I've used the precise values only for bearing calculations, as I think that this is most important. high_precision_coord_v1.patch http://gis.19327.n5.nabble.com/file/n5783533/high_precision_coord_v1.patch Please let me know what you think about it. This sounds interesting. I tried it out on finland.osm.pbf, wondering if it would make some of the bogus warnings for anti-islands go away. (There are some very tiny islets or rocks mapped as natural=coastline.) I guess, it is to be expected that your patch does not yet fix bogus warnings about the direction of hyper-precisely mapped roundabouts or tiny coastline polygons. Here is an example that I got with your patch: 2013/10/31 21:16:32 WARNING (SeaGenerator): 63240002.osm.pbf: Converting anti-island starting at http://www.openstreetmap.org/?mlat=60.21780mlon=25.30937zoom=17 into an island as it is surrounded by water This is http://www.openstreetmap.org/browse/way/241289746, a tiny islet, properly mapped in counterclockwise direction. For some reason, current svn head (r2795) with your patch is producing more error messages than the revision I used earlier (I guess r2640). With the old mkgmap, I got 545041 bytes of log, and with the patched r2795, I got 774890 bytes, for the same input. The map sizes grew too: Length MethodSize CmprDateTime CRC-32 Name 142065664 Defl:X 113283124 20% 2013-10-31 05:23 05eede3d gmapsupp.img 143736832 Defl:X 114490132 20% 2013-10-31 05:23 662f2ea9 gmapsupp.img (The timestamp is that of the finland.osm.pbf file.) Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
