Activity for Michael Bechtold
-
Michael Bechtold posted a comment on ticket #1304
PS: as a "cheap" workaround you can add a column type "size difference" and make it sortable
-
threshold for size difference
-
@Bob: RTFM Quote from MOBAC format documentation: Atlases created after another are merged into one Database named [AtlasName] atlas.sqlitedb which is located in the atlas output directory.
-
@Laurent: you simply use the same DB name in the profile (DB type Big Planet e.g., will use simplest possible sqlitedb data model) and execute them one after the other - even parallel processing is doable, as long as the write phases into the DB do not overlap. (Patience is more peace of mind here :-)) Once you have such a DB file, you can use it as a local source, which has NO limits For Bob this would mean: respecting the download limits - for good reasons as Robert advised - and execute those...
-
@Laurent: you simply use the same DB name in the profile (DB type Big Planet e.g., will use simplest possible sqlitedb data model) and execute them one after the other - even parallel processing is doable, as long as the write phases into the DB do not overlap. (Patience is more peace of mind here :-)) Once you have such a DB file, you can use it as a local source, which has NO limits For Bob this would mean: respecting the download limits - for good reasons as Robert advised - and execute those...
-
I am not relying on tilestore for my world maps. But rather use sqlitedb. Such DBs can accumulate any number of tiles. No need for merging, just feed this DB via multiple profiles. Then you have a local source for which no limits apply. Without a single line of code, nor change to MOBAC. Cheers Michael
-
I am generating maps with 1m+ with current MOBAC. So there must be subtle difference in settings and configurations of profiles and sources.
-
PS: in 2.3.1 there seems to be no boundary information in the meta data if there are multiple maps on the same ZL. I would consider the UNION (i.e. no intersection at all, very simple change) as described earlier for a future release - or go just like 2.3.1 in this regard.
-
I've checked with Orux and Locus - two major App that can handle MBtiles. Both - and I assume any other smart Geo App - can handle gaps in zoom level of a map, one way or another. Hence I consider the "all" ZL requirement of the MBtiles spec purely academic and irrelevant in the practical world. So my proposal is to revert the 2023-03-19 introduction of "one map per ZL" check. Even Rainer could live perfectly using the 2.3.1 (without that check) with Laurent's hint. I've created the respective feature...
-
revert the 2023-03-19 introduction of "one map per ZL" check - or make that optional
-
I've checked with Orux and Locus - two major App that can handle MBtiles. Both - and I assume any other smart Geo App - can handle gaps in zoom level of a map, one way or another. Hence I consider the "all" ZL requirement of the MBtiles spec purely academic and irrelevant in the practical world. So my proposal is to revert the 2023-03-19 introduction of "one map per ZL" check. Even Rainer could live perfectly using the 2.3.1 (without that check) with Laurent's hint.
-
No problem, Laurent. Your reasoning made me step back a bit and rethink: - there is only one filed in MBtiles that carries the boundaries, right? - and it shall contain the maximum area, right? - if 2x "yes": as - mathematically - the min/max function for bounds is associative, the order of evaluations is meaningless for the result - hence you simply do what you do today, but for each and every map you find anyware, and just discard the restriction. Brute force the boundary would be a global variable,...
-
Help me out, pls. Does MBtiles 1.3 require that ALL tiles for ALL ZLs must be available? If not, my ZL10 definition is not a problem. To fulfil the difinition is a broader sense you have to do min/max evaluations between all ZLs, which I conclude MOBAC does today. The only difference I propose is, how the boundaries of each ZL are calculated: you from each map of the same ZL you compare against previous boundary and extend as needed by the additionl coordinates. Straight forward, does not change...
-
PS: proposed solution would not be a special version for me, but (MOBAC 2.3.4) would solve the problem for everybody, without the 2.3.3 restriction.
-
Merci beaucoup, Laurent, for your efforts. Yes, I could restructure along the lines you describe - or stick with 2.3.1 ;-) And wait for a version that easily does this: build the min/max LON/LAT for a collection of maps of the same level. It will deliver the rectangular bound around all of them, which will help Orux and all others. And get rid of the artificial restriction of 2.3.3 What I do not understand: for years I've provided MBtiles for OAM, compiled by MOBAC 2.3.1 and earlier (!), and Orux,...
-
It was late - and indeed I attached the wrong file; sorry for that. The one I gave around midnight works here, too, while the new attachment below runs into the reported error with 2.3.3 - 2759.
-
Really weird destruction by copy/paste. Sorry for that. Here is the xml file.
-
Here we go: <atlas version="1" name="OAM-World-1-10-J80" outputformat="MBTiles"> <layer name="W1-8"> </layer> <layer name="W9"> </layer> <layer name="AmericaNorth"> <polygonmap maxtilecoordinate="116919/129216" mintilecoordinate="0/53248" mapsource="OAM-World-1-10-J80" zoom="10" name="AmericaNorth 10"> <polygon> <point>0/53248</point> <point>116919/53248</point> <point>113000/61952</point> <point>94838/92464</point> <point>88135/99312</point> <point>85812/103150</point> <point>85260/106494</point>...
-
But 2.3.3 does have an issue. Also: it is straight forward to build the min/max LON/LAT for a collection of maps of the same level. It will deliver the rectangular bound around all of them, which will help Orux and all others. And if I understood correctly, only the largest bounds matter, which may not be from the ZL of the multi-map ZL.
-
TXs for the link - I remembered there was a discussion last year, but I could not find it. On the other hand: V 2.3.1 which seems to fix the issue behind Orux/bounds according to that link thread and it has no issues with my multiple maps for the same ZL.
-
java -version openjdk version "17.0.6" 2023-01-17 OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10) OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode, sharing) Windows 11 Pro But MOBAC 2.3.1 works like a charm on exactly same environment.
-
I've switched versions to reproduce the error: Map source format incompatible - multiple maps exist for zoom level 9. Only one map per zoom level allowed. ...
-
Refuses means that MOBAC displays an error message when pushing the create button. version is 2.3.3 Last working version I have is 2.3.1
-
I have multilayer defined as well. And a world map e.g. for ZL 10 consists of a collection of maybe 10 polygons all for ZL 10. For the end result neither me nor MBtiles care about the origins. But why on earth does new MOBAC denies the multiple polygons? What is the benefit of such restriction??
-
I am building the world maps for openandromaps.org. And some sources are organized around continents. MOBAC used to compile them seamlessly since many years. Besides that: the way MOBAC builds MBtile databases, there is nothing like "distinct maps". Tiles is just a flat table, no information about where any tile comes from. Hence to me this new restriction does only harm users but not add any value.
-
Hi team, I double checked the MBtiles database structure and content: neither the metadata nor the tiles table have any notion of map id or alike that would differentiate between multiple maps of the same zoom level. Hence, why on earth would MOBAC deny processing such? Do I miss a point here? TXs and cheers Michael
-
I see where you are coming from, Laurent. Both of your points were the reason I started building these OAM world maps (raster :-) for the lower zoom levels, where vector simply sucks in terms of result and performance. For ZL 12 up I do not see performance issues, even with older phones, though. Hence I use a combination of those world maps and vector maps (OAM) for my purposes. When trying James' 4UMaps theme with OAM, it seemed to me that is is faster than Elevate, but I did not do measurements...
-
@Laurent: Have you tried at all the way I outlined?
-
Have you tried at all the way I outlined?
-
And I very much disagree with your statement re. raster quality as a general judgement. I am using vector maps plus a lot of curated content to produce World maps for lower zoom levels (up to 10 for typical users, but also up to 11, 12 or 13 for several regions of the planet, available from OAM web site. zoom level 10 and below is where raster rules. From 14 up, vector maps are just perfect re. efficiency. And apps like Locus, Orux and more can handle both types of data with equal ease. And download...
-
noone - one of the many surprises with keyboard automatic substitutions ;-)))
-
PS: and the discussion above is about various languages support by this theme. Something that did not exist in the 4UMaps web version at all, if I recall correctly (you would have needed either storage for each language, or do rendering on the fly).
-
Hi Diego, the OLD way to use 4UMaps is history, and I see Boone around who would rebuild the old mechanics on a new platform (computing power, storage, network transfer volume). What James did was to adapt one of Tobias' themes to look like 4UMaps. Theme??? Well, OpenAndroMaps (OAM) provides cool VECTOR maps that you download to your smartphone first of all. Then add James' theme, and of course you need an App like Locus or Orux to do the work ON YOUR DEVICE. I.e., once set up, you can stop your...
-
Not yet published, but latest message in Locus forum - see link above - announces it will be soon.
-
Not Yeti published ,but latest message in Locus forum - See linkbabove - announces it will be soon.
-
As you can imagine there are numerous forums where this topic pops up. The latest and most promising I am aware of is this: https://www.openandromaps.org/oam-forums/topic/integration-von-4umaps#post-55237 In essence it means: take openandromaps .map files from above site, which are vector maps, and apply James' (user jtkorken) theme and you are near the appearance of the late 4UMaps. Even with the benefit that you need zero internet, once you have installed both, the region map(s) you are interested...
-
Hi Marcus, I would assume that you have the last production run results still available, right? Hence an sqlite-DB with the tiles for each country should be doable. I am hosting (via torrent) a number of Wikipedias (Aard and Kiwix). Some DBs with for most frequent 4UMaps.eu areas I could add. For the time being. Re. long term: today I saw a request to Christian (OAM) to evaluate if a theme for the OAM vector maps could reproduce the 4UMaps. Then all the massive tile storage and traffic would go away,...
-
Hi Robert, besides my 1:1 mail to you recently, I found more of similar issues. This is not like the cut labels that we suffer from because we cannot have a label layer in a reasonable way. This is about peak captions being fully and correctly visible at ZL 12, e.g., but gone at ZL 13. Any idea why that may be? Maybe a new MapsForge lib (there has been quite some work on it) could help? TXs and cheers Michael
-
Indeed I missed this loophole :-(( But you could bind the dynamic limit to a window of a day e.g. (with hashed values (date and online tile totals so far) for persistence in cfg file). And an missing file or hash shall cause a delay of one calendar day :-) I fully understand and support good citizenship, i.e. not abusing online services. People with enough IT knowledge can always create a MOBAC with a different limit - you will never catch them in an open source world. But
-
Currently the limit is static in the sense that it compare against the calculated tile number of a map definition. Imho it makes sense to have a dynamic approach instead, i.e. counting the effective internet downloads. If you have everything local, then you will never hit the limit. What do you think? Cheers and all the best for 2022 Michael
-
Currently the limit is static in the sense that it compare against the calculated tile number of a map definition. Imho it makes sense to have a dynamic approach instead, i.e. counting the effective internet downloads. If you have everything local, then you will never hit the limit. What do you think? Cheers and all the best for 2022 Michael
-
BINGO - works like a charm. TXs a lot, Robert!
-
One more (off topic) thing: could this be interesting re. missing labels ? https://github.com/mapsforge/mapsforge/commit/6f8312f43724a84ccc1dbc962dbeb7a0c076061e
-
BTW: it needs larger map generation runs to produce the error. Each one producing 500 MB+ maps should do.
-
This is under W10, but also happened under W7, if I recall correctly /# of maps was smaller back then, so I took the pain :-) java version "1.8.0_161" Java(TM) SE Runtime Environment (build 1.8.0_161-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)
-
MOBAC crashing when producing JPEG tiles for two maps in parallel
-
TXs. Done. M
-
Hi Emmanuel, with the new massive funding I read about recently, is there a chance that such will be implemented ?
-
Hello Emmanuel, I suppose the definition of the problem is clarified, right ? Any idea when this will be fixed, pls. ? It cannot be much of an issue. Only "tell" Android that Kiwix is "interested" in this type of Wikipedia links.
-
Exactly, such type of link. I am offered Chrome, Firefox - and Aard2 as Apps to take over the link and serve.
-
OK, in Android you can have a link that "points" to a Wikipedia entry. Android has a number of Apps registered that serve such links. Web browser (Chrome e.g.), or Aard2, are both offered. The Kiwix App is not offered, although it can handle Wikis and Wikipedia. Why is that, pls. ?
-
Any news here, pls ?
-
That works: convert $capfile -crop 14x8@ +repage +adjoin -define png:color-type=6 h%d.png
-
Not working - when I show those tiles only, the saturation is correct. HOWEVER, when using them as an overlay, there is no transparency any more - bummer ... Playing with other options now.
-
Workaround: convert $capfile -crop 14x8@ +repage +adjoin -define png:color-type=2 h%d.png Colortype 2 forces truecolor, and MOBAC now shows the expected outcome :-)
-
That is WEIRD !! All of those files are the result of ONE command by ImageMagick: convert $capfile.bak.png -fuzz 20% -transparent white -crop -$CROPW+0 -crop +0-$CROPH +repage +adjoin $capfile Then the files are the put into the right place in a Maverick like structure. The difference seems: when there is a capitals (province, state, country), a real color comes into the picture, while else it is only B/W/grey and ImageMagick seems to optimize as good as possible. While we are not in control of Java,...
-
PS: I went back to Java 8-121 as well to rule out that my recent upgarde to 131 causes the issue - same problem with 8-121
-
Hi Robert, this is the map source: <localTileFiles> <name>CapitalRepair</name> <sourceType>DIR_ZOOM_X_Y</sourceType> <sourceFolder>G:\Dropbox\MOBAC\MapCreation\atlases\CapitalRepair\</sourceFolder> <backgroundColor>#000000</backgroundColor> </localTileFiles> and that is all well understood and fine. Did you have a look at all 3 screenshots attached ? You will see that the left tile of the screenshot is bad quality and the right tile is as it should be. While the source tile files (88w and 88e) are...
-
Broken display and handling of partly of tile saturation and brightness
-
Implement geo coordinate search
-
Kiwix does not react on Wikipedia link on Android
1
