[mkgmap-dev] gui for areas.list ?

Fri Aug 28 17:46:06 BST 2009

On Tue, 25 Aug 2009 15:18:16 +0000 (UTC), Chris Miller wrote:
> L> Most of the stuff should be done client side (OL) and the tiles
> L> originate from the OSM server, so there won't be much that bothers my
> L> server. But I don't know if you're willing to add a link to a page on
> L> a not-affiliated (not directly anyway to the splitter tool) server
> L> from within the code. It seems prone to failure some day ;) A link on
> L> the Mkgmap/splitter wiki page seems more appropriate to me.
> 
> Steve's probably the best person to comment on linking to external sites.

> But wrt the chance of the url changing/breaking in the future, I was
> intending 
> to make it configurable anyway. My idea was to be able to specify
something
> 
> like --launchKML, and a browser window would be launched once the
> subdivision 
> had taken place, showing the user something like this:
>
http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=http:%2F%2Fwww.mkgmap.org.uk%2Ftmp%2Fareas.kml&ie=UTF8&z=3
> 
Sorry for not responding earlier, I missed this one.

I don't see the big advantage of having splitter start the browser with a
KML argument. It is a simple task for a person to launch Google (or
another) site and pass the kml file manually. So I think you can spare
yourself the trouble of implementing this.

> If you can think of a way to do that without having to serve the KML file

> from a server somewhere, I'd be interested to hear your ideas.
> 
I can't think of any other way either. 

> 
> L> the tiles rendered with Mkgmap. The red tiles in Denmark are caused
> L> by all the house numbers which cause the guesstimate mechanism
> L> (--max-nodes) of splitter to be fooled in thinking that Mkgmap could
> L> produce working maps for those areas. Splitter should be more
> L> intelligent about determining the max size of an area, ultimately.
> 
> Ahh yes, that rings a bell now that you mention it. I'm open to
suggestions
> 
> on how this could be improved, unfortunately I don't have enough
experience
> 
> with the limits yet to know what might be the best approach. At this
stage 
> I'm thinking about building up a low-res "density map" (for lack of a
> better 
> term), which would divide the world into MxN areas (probably with their
> boundaries 
> aligned to suit the map resolution) and then tally up the number of
> nodes/ways/relations 
> in each area. Those aggregations could then be used to decide how to
group 
> areas together into larger tiles. I can see a lot of advantages to this, 
> for example:
> 
> - The nodes/ways/rels could contribute different (easily customisable)
> weightings, 
> so we can experiment to find the best balance.
> - The algorithm that decides how to group the areas into tiles would be
> easy 
> to adjust and could even be made pluggable.
> - High density areas could be identified and placed in the middle of a
> tile, 
> rather than cut through the middle as is the tendency with the current
> splitter 
> (see eg London).
> - The density map could be paged out to disk and the subdivision
performed 
> on a portion at a time to save memory without much of a performance hit.
> - The density map could be handed off to a tile editor tool so users
could 
> take tile complexity into account.
>
This sound like a lot of work for you and for algorithms while humans can
perform this task with ease. So perhaps the current crude (I don't mean in
an insulting way!) method might just be fine for the time being and people
can fix these kind of problems easily by hand. Especially when working on
areas.list files can be simplified through a (webbased perhaps) tool.

> I haven't yet sat down and figured out how it will affect performance and

> memory of the current splitter, but I doubt it'll be a deal breaker and
> will 
> probably even have some benefits.
> 
> What do people think (assuming you can even understand my admittedly poor

> description!)?
> 
> 
> L> But, as things are now, I'm manually editing the areas.list to get
> L> rid of those failed (red) tiles. Unfortunately, doing the splitting
> L> of the bboxes by hand is cumbersome work. I also expect mass imports
> L> and just sheer manual labour will cause many red tiles to appear in
> L> the future. These are the reasons why I was working towards a
> L> webbased UI that can do the splitting for me with a simple mouse
> L> click.
> 
> How about splitting those red areas in half again (taking care with the
> alignment), 
> rather than just getting rid of the areas completely?
> 
That is what I'm doing manually using an Excel file to do the dividing
math, but without the alignment rules (which I heard of not so long ago).
But I hate doing that kind of work so I just haven't done it for every
problem area yet (Not true actually: I've split those red tiles in Denmark
twice already but it still wasn't enough. Then I gave up for the time
being).

Or do you mean to have splitter split those problem areas again by feeding
*only* that problem area and a very low --max-nodes parameter? Because that
is a solution that I did not think about before. I just run splitter once a
week on 2 halves of the planet and if tiles fail then that's it...

> 
> L> There are also quite a few people who would like to be able to split
> L> tiles because the tiles would otherwise include bits of data from
> L> neighboring countries e.g. across large bodies of water (look at e.g.
> L> France/England/Spain, Zweden/Poland etc). I have no problem with this
> L> type of splitting result, but some apparently do.
> 
> Makes sense. I notice the real Garmin maps have tiles that must have at
> least 
> partially been crafted by hand. Eg London is covered very nicely by a
> single 
> tile, various tiles have edges along national borders, bodies of water
are 
> tiled appropriately and so on. I guess no algorithm's ever going to be
able
> 
> to match that :(
> 
I guess pure math algorithms would have a hard time, but we can feed them
the required information because we have the national border (and city)
polygons, so if Mkgmap is going to support polygons instead of bboxes then
there is a way...

In the mean time when there is a GUI then people can optimise the
areas.list quite easily. But, so far, I reckoned that having maps available
is far better then beautifully crafted tile coordinates but no maps :)