Finally its snowing, not that much but more like a real winter than the 20°C we hat here in Austria in October.
So outdoor cycling and season is more or less over and time to look back and report the improvements for OAM Maps in 2018.

Most innovations and improvements are the result of suggestions from the forum.
So I recommend to take a look at the forum area from time to time.
Click here for the forum topic “Elevate News” where @Tobias constantly reports the numerous improvements of the Elevate / Elements rendertheme.

This works without registration. If you want to register please make sure to use a “reputable” email address – the spam filter is strict cause otherwise I have to delete not 5 but 500 fake / spam registrations every day.

So here are the most important improvements for the OpenAndroMaps 2018:

– Mapborders: Skipped / missing Relations (white lakes eg.)

The problem was that rendering of OSM Objects like roads, forrests, lakes, rivers,.. was completely skipped when these objects exeeded the mapborders.
@Steffen, a “C” programmer who supported the OAM Team with his knowledge for several times, compiled a special Version of OSMCONVERT that  now _really_ works on Windows7/64 and preserves these objects. So now lakes are blue even when these exeed the map-coverage. Most important is this for the Great Lakes in Canada an Africa.
And – now its possible to simplify map borders with a better coverage cause map borders now can cut through lakes without loosing details.

– Map-Coverage:

For most of the 280 maps the coverage / mapborders have been simplfied.
This looks much better, the problems for rendering objects at the borders are reduced – lots of work but for 90% done now.

– Priority for rendering places and data-cleanup for peaks:

@Michael has finished a monster-project. He worked through all “places” in the OSM database and assigned kategories to places depending on the population of these places. This means assignement of places to zoom-levels now is much more accurate than before – this a huge improvement.
Second @Michael has worked through all “peaks” and cleared all foulty ele-tags like elevations set in “feet” cleared to “meter”, eliminated wired chars… – so now the algorithms from @MaxBe work on a clean databbase resulting in accurate rendering of peaks and saddles.

– Cycle Lanes / Oneway

Improved rendering of several more variants of cycle-lanes in conjunction with “oneway”

– Contourlines

@Sonny has firther improves the integration of free LIDAR (Laser) elevation data.
For detail maps of Great Britain we spipped from Viwefinder3 elevation data to the improved NASA SRTMV3 1″ Dataset with 10m contourlines:

  • UK_Scotland
  • UK_Wales (new)
  • UK_LakeDistrict (new)
  • Ireland

– Lots of minor improvements

Like rendering of house_numbers assigned to Relations,
Map of Pyrenees now covers whole Northern Spain from Atlantic to Mediterranean Sea so hikers on the Jakonsweg need only one, small map for Northern Spain,
….

 

The OAM-Team wish you a pleasant a Winter!

 

Elevate updates don’t bring huge changes anymore, but smaller ones, that, when added up, make a big difference altogether. Therefore once again the hint here that only with current map styles and maps all improvements get visible. Recently those were important changes in Elevate, and some smaller ones as well. Look at the legend for further information.

  • a new overlay for extended road surface information
  • new via ferrata rendering
  • solid/dashed borders for cycleways
  • changed visibility information for paths without sac_scale
  • prominent peaks are now shown earlier and, if the app supports it, are prioritized
  • hiking waycolor is displayed along waymarks
  • the overlay contents have been rearranged a bit
  • access limits are much more accurate to the mode of transportation the map style is made for

The newest downloads and the changelog can be found as always on the Elevate page, and for e-mail notifications for further updates of Elevate just subscribe to this thread in the forum.

Best regards,
Tobias

The OpenAndroMaps website will switch to secure transfer protocoll  according HTTPS / SSL this week.

This step is required by the Google guidlines to provide the HTTPS / SSL for all sites that require user inputs such as comments, user accounts, or forums.
This is an important step ahead in data security, which has been supported on the side of OpenAndroMaps since long by flanking, server-side actions like Intruderdedection, protection against BruteForce attacks and integration into various blacklists.

 

UPDATE 2017-08-22 18:00h MEZ: Done, the Website is running on fine on SSL, no mixed contend any more – we have a green lock-symbol on all pages. I  have tested all functions and have’nt found any bug. However, if you experience problems please post here as comment or in the forum.

Best regards, Christian

Hi,

This is an information for Theme-Composers.
There will be an important change in tag-mapping for the OpenAndroMaps.

Until today sac_scale was preprocessed to carry only 4 levels:
T1,T2,T3 and T4, while T4 included T5+T6 too.

Now sac_scale will be extended for all levels = T1 – T6 (August update), so seperate levels for T1,T2,T3,T4,T5,T6

This includes some minor changes:
DAV_SCALE “black” is transformed to SAC_SCALE=T5 (was T4 so far)
If a way includes any “via_ferrata” tag/value SAC_SCALE is set to “T6” (was T4 so far)

_and_
in a second step (October) raw_sac_scale will be no longer supported = removed from Tag-Mapping!

SO: sac_scale T4 will NO LONGER INCLUDE T5+T6 > T5 AND T6 are seperate values from August update on.
THIS MEANS: You have to extend existing rules for sac_scale=T4 to “sac_scale”=”T4|T5|T6”
AND existing rules for “raw_sac_scale” have to be extended to “sac_scale|raw_sac_scale”

Please prepare your themes.

This have to be made in a 2-step process:

Extend your rules so that sac_scale prozesses T5 and T6 too.
So if you have a rule :

    <rule e="way" k="sac_scale" v="T1">
          <line stroke="#FFAA00" stroke-width="0.65" stroke-dasharray="17,1" stroke-linecap="butt" />
    </rule>
    <rule e="way" k="sac_scale" v="T2">
           <line stroke="#3052FF" stroke-width="0.65" stroke-dasharray="17,1" stroke-linecap="butt" />
    </rule>
    <rule e="way" k="sac_scale" v="T3">
           <line stroke="#FF0000" stroke-width="0.65" stroke-dasharray="17,1" stroke-linecap="butt" />
     </rule>
     <rule e="way" k="sac_scale" v="T4">
           <line stroke="#000000" stroke-width="0.65" stroke-dasharray="17,1" stroke-linecap="butt" />
     </rule>

extend it to:

      <rule e="way" k="sac_scale" v="T1">
          <line stroke="#FFAA00" stroke-width="0.65" stroke-dasharray="17,1" stroke-linecap="butt" />
      </rule>
      <rule e="way" k="sac_scale" v="T2">
          <line stroke="#3052FF" stroke-width="0.65" stroke-dasharray="17,1" stroke-linecap="butt" />
      </rule>
      <rule e="way" k="sac_scale" v="T3">
          <line stroke="#FF0000" stroke-width="0.65" stroke-dasharray="17,1" stroke-linecap="butt" />
      </rule>
      <rule e="way" k="sac_scale" v="T4|T5|T6">
          <line stroke="#000000" stroke-width="0.65" stroke-dasharray="17,1" stroke-linecap="butt" />
      </rule>

from October on you can create additional, seperate rules for T5/T6

If you use a raw_sac_scale, extend the rules:

       <rule e="way" k="raw_sac_scale|sac_scale" v="RT1|T1">
          <some settings..../>
      </rule>
      <rule e="way" k="raw_sac_scale|sac_scale" v="RT2|T2">
          <some settings..../>
      </rule>
      <rule e="way" k="raw_sac_scale|sac_scale" v="RT3|T3">
          <some settings..../>
      </rule>
      <rule e="way" k="raw_sac_scale|sac_scale" v="RT4|T4">
          <some settings..../>
      </rule>
      <rule e="way" k="raw_sac_scale|sac_scale" v="RT5|T5">
          <some settings..../>
      </rule>
      <rule e="way" k="raw_sac_scale|sac_scale" v="RT6|T6">
          <some settings..../>
      </rule>

So everyone making themes for OpenAndroMaps have to ensure that everything renders fine when expanding the sac_scale and finally deleting raw_sac_scale. I know its annoying – however there is no other way to ensure that the maps render fine in future.

Additional TAGS that will be removed from tag-mapping by end of October:

  • raw_sac_scale (as mentioned above)
  • incline_dir
  • class_bicycle_mtb, class_bicycle_road (maybe we find a solution to transform _mtb to existing tags)
  • noexit

I’m terribly sorry about this, however recently I discovered that there is a limit of max. 15 Tags in the MapsforgeWriter per OSM_Object so I have to reduce the amount of tags – otherwise we end up in white tiles rendering the maps at is was the case with parts of upper Austria last weeks.

See discussion of this issue at MapsforgeDevGroup:
https://groups.google.com/forum/?fromgroups=#!topic/mapsforge-dev/kQKfCMGk2Ec

Best regards
Christian

Multilingual maps- what does this mean?

As an example: The OpenStreetMap database provides NAMES for most objects like Citys, Roads, Churches, Rivers, aso.. in different languages. So for the map of Israel usually in hebrew, arabian, english, maybe in german. For maps of Russia usually in russian and english.

Up to now only one language per maps was possible to include and display on our smartphones.
So providing two languages for one maps for OAM meant making –  and for you, downloading two different maps.

With the new, multilingual maps it is possible to include different languages while making the map and switching map-language in an APP – if an APP is compatible with these maps AND provides a language switcher. This is the case for ORUXMAPS and LOCUS for Android and Cruiser for Android + PC.

Here you see a small screencast of ORUXMAPS switching between russian and englich using the map of Moscow:

Orux-Multilingual_Maps_OAM[EN]

So we decided to provide the multilingual maps on OpenAndroMaps.
The effort for providing two different versions of the maps (old single and new multilingual = 250 each) is crazy.
However, we are aware that a lot of APPs still only support the old “V3” single-language maps – and keeping our users in mind we will support both versions for while, as far and long as our resources will allow this.

For now we provide the new multilingual “V4” maps for download to PC AND for direct install to ORUXMAPS. The download/install buttons for these maps are RED, the included languages are shown for each map as abbreviations in square brackets. The new map files itself are identified by a “_ML” suffix.
So, eg., while the name of old map is “Germany.map” the name of the multilingual map is “Germany_ML.map”

For more information klick here

The old maps that we provided in different languages will be available in future only in one language (usually native lang. or english) – this is the case for all russian mapps, several maps for Asia aso. PLUS the multilingual version.

The POI files for the multilingual maps are included in the zip-files of the maps. With the next update of ORUXMAPS these POI-files will be installed in the right place on your Smartphone if chose direct install.

 

Next posting will deal with the complete redesign of the categorie-structure of the OpenAndroMaps POI-files.

Best regards
Tobias & Christian

The planed “maintenance” of the OpenAndroMaps website ended up in renting a new, performant server with the latest operating system in a fast network …..

Furthermore, several overweight plugins were exchanged against lightweight ones from GitHub and everything was adapted to run under PHP7 – this should be fine for the next months.

The advantage for you: fast response times (around the 400ms load time) after I have spent a full weekend with the memcached server  :-).
The page rendering times on Android is not so nice, unfortunately this is a common problem on these devices.

SPAM: I’v installed a new Spam-Protection. Please dont use disposal EMail addresses, this will not work.

Now we can concentrate on the real thing: Making maps, pois, themes, docs.
Maybe some of you have already seen that multilingual maps now available for download – we will present these maps in brief later on.

See you
Christian

Dear OpenAndroMaps Community!

 

Unitl now the map starting position after loading a new map was set to the arithmetical center of the area the map covered.
Unfortunatelly sometimes, at high zoom levels and with GPs device disabled, you ended up in the blue sea or in the middle of nowhere after loading a map.

From now on every map has its own starting position set by hand – usually the capital of the country/region or a well known natural preserve or something like this.

As an example: Loading a fresh map of Cannary Islands – until know you ended up in the blue sea, from now on the map starting point will be N28,46560°  W16,25398° = Santa Cruz de Tenerife.

This improvement is the reason why the update for March is delayed for a few days – the map starting points for ~270 maps have to be defined. The updated maps should be available from 7th of March on starting with Europe/Germany.

 

best regards
Tobias & Christian

Most of the hiking symbols tagged in OpenAndroMaps are now included in the OpenAndroMaps.
Redering of these symbols follow the rules of  Waymarkedtrails .

Important: If more than one route is assigned to a way : The waymark for the route with the highest priority is rendered = iwn, nwn, rwn, lwn.

Please download the latest maps and the latest version of the Elevate rendertheme and activate the rendering of the hiking symbols in your APP.
in the Elevate theme the background symbols appear at zoom-level 13, the whole symbols (background,foreground,text) appear at zoom-level 15.

Further details and rules for osmc:symbols at OpenAndroMaps can be found here

Austria and South Tyrol has finished the LIDAR Laserscans and released this dataset to the public for free.
@Sonny converted it to usual hgt files and published it for download:

http://data.opendataportal.at/dataset/dtm-austria
http://data.opendataportal.at/dataset/dtm-german
http://data.opendataportal.at/dataset/dtm-slovenia
http://data.opendataportal.at/dataset/dtm-spain

For the OpenAndroMaps this means that serveral Maps benefit from these new elevation data, and believe me – the difference is incredible.

  • Austria
  • Alps (Austria und South Tyrol)
  • Alps_Ost
  • Italy (South Tyrol)
  • Berlin, RheinlandPfalz
  • Slovenia
  • Spain

I strongly recommend you to update these maps, especially if you are a mountain hikers or MTB enthusiast.

Here in this Thread you can see examples of various tiles [DE]

 

After an extended testing period Elevate 4 has been released today. The map key was also updated.

Downloads as alway on the Elevate page.

Major changes:

  • One size only: SVG version which scales with screen density is now default, no more different sizes.
  • All graphics are scaleable: all symbols and patterns are now displayed with scalable vector graphics and scale with screen density, instead of pixel based PNG files. For example patterns like those on private roads are now scaled and should be better visible on high density screens.
  • Routes: national and international routes have seperate colors (same for hiking and cycling, blue and red, so I had to change regional cycling routes as well), hiking routes colors match now those that are used for hiking routes in some areas. General route rendering has been optimized as well.
  • Mountain Bike: seperate MTB map style with rendering of visibility of paths and with new rendering for mtb_scale_uphill
  • Locus: Locus version includes now Locus Edition (LE) versions for single language V3 maps and standard Elevate for multilangual V4 maps. All objects scale now much better in Locus LE.
  • Access limits: those are filtered now, a way with only private/no access is only rendered as that in hiking (or cycling) mapstyle, if this access limit is also valid for pedestrians (or cyclers). Only the city mapstyle shows general access limits.
  • And many more smaller additions and optimizations.
Elevate 4

The new MTB map style of Elevate 4