seen from China
seen from Netherlands
seen from United States
seen from T1
seen from China
seen from Taiwan
seen from United States
seen from United States
seen from France
seen from Brazil
seen from Italy
seen from Estonia
seen from United Kingdom
seen from Germany
seen from Netherlands
seen from United States
seen from United States
seen from Canada
seen from United Kingdom
seen from Russia
Art by @mamboleoolab Everest - 8 848m #webgl #threejs #maperitive #mapporn #generative #generativeart #generativedesign #procedural #javascript #canvas #processing #hiking #mountain #everest https://www.instagram.com/p/CfWut3TLQAb/?igshid=NGJjMDIxMWI=
Anya is live and ready to show you everything. Watch her strip, dance, and perform exclusive shows just for you. Interact in real-time and make your fantasies come true.
Free to watch • No registration required • HD streaming
Maperitive: Alpenglow Effect Using A Custom Shader
 The [latest release](http://maperitive.net/download/Maperitive-latest.zip) comes with a new Python script called Alpenglow.py which renders a hillshading relief adding some yellowish tint to illuminated high slopes to enhance the 3D effect. It was inspired by the "[See the light: How to make illuminated shaded relief in Photoshop 6.0](http://www.shadedrelief.com/illumination/index.html)" article on the excellent [shadedrelief.com](http://www.shadedrelief.com/) site. You can run the script by executing run-python Samples/Python/Alpenglow.py The script generates the hillshading for a fixed map area in Switzerland, but you can change this quite easily in the script. You can also change other parameters, like shading (and alpenglow) colors, elevation ranges etc. The script also demonstrates the power of writing a **custom shader**. A shader transforms a small part of the digital elevation model (DEM) into a pixel color, based on the elevation, aspect and the slope of that part of the DEM. This way you can write your own hillshading effects function and then supply it to the generator. Here's how it's done for Alpenglow.py: # Execute the hillshading bitmap = ReliefUtils.generate_relief_bitmap(dem, relief_bbox, Srid.WebMercator, 1, alpenglow) The last parameter of the generate_relief_bitmap function is the shader function, in our case called alpenglow: # The actual shader function which is called for each pixel of the hillshading bitmap. # It receives the elevation, the aspect (orientation) of the slope and the steepnes (slope). def alpenglow(elevation, aspect, slope): sin_slope = math.sin (slope) nx = math.cos(aspect) * sin_slope ny = math.sin(aspect) * sin_slope nz = math.cos(slope) direction = dotproduct(nx, ny, nz, lx, ly, lz) direction = (direction - minDirection) / (1 - minDirection); if direction < 0: direction = 0 # This is how we can mix two colors together. shade_color = shade_base_color.mix (light_color, direction) if direction > 0.0 and elevation > min_alpenglow_elevation: elevation_factor = min((elevation - min_alpenglow_elevation) / delta_alpenglow_elevation, 1); alpenglow_factor = math.pow(direction, 4) return shade_color.mix (alpenglow_color, elevation_factor * alpenglow_factor).argb; return shade_color.argb;
Mercator's Egg
UPDATE: my math was buggy, the eggs look a bit different after the correction. Note that the formula fails on very large distances (> 2000 km). A little Maperitive Python script I was playing with today, showing the line of distance of 3000 km (larger egg) and 2000 km (smaller egg) from my home town of Maribor, drawn on the standard Web Mercator projection map:  Here's the script: from maperipy import * import math location = Point(15.6530555556, 46.5575) distance = 3000000 layer = Map.add_custom_layer() symbol = PolygonSymbol("circle", Srid.Wgs84LonLat) symbol.style.pen_width = 8 symbol.style.pen_color = Color("blue") symbol.style.pen_opacity = 0.5 symbol.style.fill_opacity = 0 earth_circumference = 6371000 * math.pi * 2; points = [] arc = distance / earth_circumference * 360; for angle in range(0, 360): radians = math.radians(angle) y = location.y + math.sin(radians) * arc lat_factor = math.cos(math.radians(y)) x = location.x + math.cos(radians) * arc / lat_factor points.append(Point(x,y)) circle = Polygon(LinearRing(points)) symbol.add(circle) layer.add_symbol(symbol)
Oxford Bus & Cycle Map in print
I've just received the "Oxford Bus & Cycle Map" from Richard Mann (thanks, Richard!). The interesting thing is that it was made from OpenStreetMap data using Maperitive. It's a stunning beauty, Richard has put a lot of effort into it. Online versions of the maps are here: http://www.transportparadise.co.uk/maps/   
Results Of The Maperitive Survey
Last week I posted a [quick survey for Maperitive](https://docs.google.com/spreadsheet/viewform?formkey=dHNoNFVmbGNLN0VZRFcyRG9sdERTMUE6MQ) users. The basic motivation was to see how many people are still using Windows XP SP2, so I can decide whether I can migrate Maperitive to .NET 4.0 (which is not available on SP2). But I added a few more questions in the mix, just for the fun of it. I got 138 reponses so far, which is much more than I expected, so thanks for everyone who participated. The results (I just copy&pasted charts from Google Docs, sorry for the labels cut-off): ### What operating system(s) are you using to run Maperitive?  Participants could choose multiple answers - in fact about 1/4 of participants were using Maperitive on multiple operating systems. About 4% of people marked they are using Windows XP SP2 - I am wondering what is the reason they haven't upgraded to SP3 (my guess is they are using Maperitive in corporate environments which tend to be slow on upgrades). Two things that I think are important from these results: 1. **I can start work on migrating to .NET 4.0**. For those unfortunate few who will be left out by this I can only say: **try to upgrade to Service Pack 3**. The official .NET 4.0 has been released two years ago (and first beta was released back in 2009) and it's increasingly hard to support development on older versions of .NET framework. 3rd party libraries Maperitive depends on have mostly migrated to .NET 4.0 and this means missing out on new features and bugfixes. 2. **A lot (50%) of people are using Maperitive on Linux and Mac**. This is much more than I expected and it means I will still have to keep Maperitive running on Mono. This is sometimes hard, since not everything is supported by Mono correctly. It also means a lot of people are willing to put up with an inferior user interface (due to Mono porting issues) for the sake of the functionality Maperitive offers. This is complimentary. ### What it is the main reason you're using Maperitive?  No surprises here, other than that at least 1/3 of users find Maperitive simple to use. This is a high number, given the fact that the documentation is not that good. There's one interesting (and a little bit surprising) answer: > _We can use OSM offline, without prerendering thousands of tiles. It is very helpful for emergency services, because you cannot rely on a mobile internet connection everywhere or in the case of a disaster._ ### What kind of a user do you consider yourself to be?  Looks like the main audience of Maperitive are users who like to hack. Only 18% of participants in the survey consider themselves to be non-technical. I guess that explains the large "simple to use" percentage in the previous question :) ### I use Maperitive mainly to...  Another question with multiple possible answers. I'm pleased that a lot of you are using Maperitive's "power tools" like tile generation and exporting. I'm also pleased that at least 37% of participants are using the SVG export functionality, which I worked hard to implement. ### I use Maperitive mainly for...  I guess I shouldn't be surprised that most of you are doing hobby mapping with Maperitive. As OpenStreetMap reaches more people (and companies), I think the percentage of non-profit and commercial usages will increase. ## Conclusion The survey is [still open](https://docs.google.com/spreadsheet/viewform?formkey=dHNoNFVmbGNLN0VZRFcyRG9sdERTMUE6MQ) (I think I will keep it open for some time), so you're welcome to have your say. There will be more surveys in the future - this one was done as an experiment, in just 5 minutes. Again, thanks for participating!
Anya is live and ready to show you everything. Watch her strip, dance, and perform exclusive shows just for you. Interact in real-time and make your fantasies come true.
Free to watch • No registration required • HD streaming
Premier essais pour mon plan de Liège.
Maperitive Beta: Subpixel Accuracy
Even though most of Maperitive work I'm doing lately is done in a separate branch that will come out as a brand new Maperitive 2.0 release some time in the beginning of 2012, I do occasionally implement some quick enhancements to the currently "unofficially" released Maperitive beta. I've just uploaded a new beta version with a couple of neat features, one of which I will describe in this post (the other will have to wait for the next post).
Subpixel Accuracy
This is an important, although probably not very well known feature Mapnik provides. What is subpixel accuracy? Simply put, it is the ability to set the thickness of the line in fractions of a pixel (image stolen from AGG's site):
Up until now this was not really possible in Maperitive. Well, you could specify the thickness as, say, 1.3 pixels, but it would be rendered as a line with thickness of one pixel, ignoring the fraction. The reason is simple: Maperitive uses GDI+ library for rendering, which doesn't do subpixel accuracy (it does support antialiasing, but that's not enough). Mapnik, on the other hand, uses superior Anti-Grain Geometry (AGG) library (you can read more about it in AGG's Introduction page, which is very interesting).
Why is subpixel accuracy important? Certain map features require delicacy. In his Cartographic Relief Presentation book Eduard Imhof gives very precise recommendations for elevation contour lines thicknesses. 0.05 to 0.08 mm for black normal contours for map scale 1 : 50,000, as an example. Without subpixel accuracy it is very difficult to come even close to such measures and then you end up with both normal and index contours (the thicker ones) having the same thickness in the rendering:
So given that I cannot directly render lines with subpixel accuracy and using AGG in Maperitive is not a practical solution because of various technical reasons I won't go into, I've more or less given up on this.
The Solution
... Until I came up with a simple but effective trick to achieve subpixel accuracy: render the whole map scaled to (say) three times and then downsample the whole image back to the "normal" scale. Before I delve into details, here's how the same map looks like using this technique:
I think the difference is obvious: you can now see two distinctive contour line types. Index lines are 1.25 wide, while normal lines have a width of 0.65 pixels.Don't worry about these numbers, subpixel accuracy is not that precise, but it is precise enough.
The Details
Subpixel accuracy can be tuned for three Maperitive commands:
export-bitmap
export-3d
generate-tiles
All of them have a new subpixel parameter which accepts a positive integer value. This value is used as a scaling factor when rendering. Once the rendering is done, Maperitive uses Supersampling algorithm to resample (downsample actually) the rendering to the scale factor of 1. So for example if you want to generate tiles using subpixel accuracy, you type in something like
generate-tiles minzoom=10 maxzoom=12 subpixel=3
Caveats
What is the best value for subpixel parameter, you may ask? I've been experimenting with the value of 3. You could try larger values, although I doubt there will be a noticeable increase in the quality of rendering. The downside of larger values is that Maperitive takes longer to render. This could considerably slow down your tiles generation, so there is a trade-off between the quality and speed (isn't there always?). Measurements of tile generation speed show that by increasing subpixel value by 1 halves the speed of tile generation. In future this should be mitigated by allowing Maperitive to render tiles using multiple processors.
You should also be aware that if you intend to use subpixel accuracy for exporting large bitmaps, Maperitive has to actually allocate a much bigger bitmap in the process of rendering. So for example if you want to create a 4000x4000 bitmap using subpixel=3, Maperitive will want to allocate a 12000x12000 bitmap in the process and will probably fail due to limitations of GDI+ bitmap size. So there is no free lunch (at least until I figure a way around this problem ;) ).
One final note: interactive map does not use subpixel accuracy since this would make the map rendering pretty slow. In future versions Maperitive will provide some kind of "map quality" / "level of detail" setting, so you'll be able to control this.
Enjoy!
Maperitive: 3D Export
The latest Maperitive beta (download it from here) now contains a new command called export-3d, which generates a 3D mesh using the digital elevation model and places the map texture on top of it. The 3D model is exported into a COLLADA format, which can be imported into various 3D programs (Google SketchUp is the one I mostly used, it's free).
Quick How-To
The quickest/easiest way to generate a 3D export is to move the map to the area you're interested in and simply select the Tools | Export To 3D menu command. Maperitive will then generate files in the output/Maperitive3D directory of your Maperitive installation. If you do not load your own OSM vector layer, Maperitive will use OSM tiles, the same ones used to show tne OSM web map.
NOTE: be careful to keep the map area fairly small, otherwise you'll end up with a 3D model that you won't be able to import into other software, especially if you don't have a top-of-the-line computer at your disposal.
Importing Into SketchUp
After opening SketchUp, choose File | Import..." menu command. **NOTE: Before browsing for the file, click on the Options... button and make sure Validate COLLADA file is turned off:
Validation should be disabled because it makes importing unbearably slow, especially for larger models. After you've done this, browse to your generated Maperitive3D.dae file and open it.
Depending on the size of your model, you might have to wait for some time for the importing to finish. Sometimes I even have to resort to killing the SketchUp process and regenerating a simpler model.
Configuring SketchUp
After the model has been successfully imported, you may want to tweak a few settings in SketchUp to make the rendering look better:
View | Edge Style | Edge - uncheck this so the edges of surfaces are not shown.
View | Face Style - choose Shaded With Textures to get the best effect.
View | Shadows - check this to turn on the sun shadows.
Tweaking The 3D Model
export-3d command provides additional parameters we can tweak. Type in help-command export-3d into the command prompt and you'll get the list of those parameters:
COMMAND NAME: export-3d DESCRIPTION: generates a 3D map from the current map view and saves it to the disk PARAMETERS: output-dir=<the directory where output files will be saved> (text, optional) mesh-points=<the maximum number of points the terrain TIM mesh should have> (integer, optional) tin-error=<the maximum allowed elevation difference (in meters) when simplifying the terrain TIN mesh (default is 1 meter)> (real number, optional) width=<bitmap width> (value, optional) height=<bitmap height> (value, optional) map-scale=<map scale to use when exporting> (value, optional) scale=<graphics scale to use when exporting> (value, optional) dpi=<DPI to use when exporting> (value, optional) zoom=<zoom level to use when exporting> (value, optional)
Better Bitmap Texture
By setting various bitmap parameters you can increase the resolution of the bitmap and/or the zoom level of the underlying OSM bitmap.
TIN Tweaks
To increase performance, Maperitive uses Garland-Heckbert's TIN simplification algorithm to simplify the terrain triangulated irregular network (TIN). There are two command parameters that affect the simplification process:
tin-error: this is the maximum error (tolerance) allowed between the actual DEM elevation and the generated model, in meters. The default value is 1 meter and if your model becomes too big to handle, I suggest increasing the tolerance value.
mesh-points: this is the maximum number of points (vertices) the TIN should have. The simplification algorithm starts from a very simple model (just two triangles) and incrementally adds new points to it. Upon reaching the maximum number of points, the algorithm stops (regardless of the tin-error setting). This is a safeguard against the model going wild with too many points. So I suggest experimenting with those two values to get something workable for your case.
Setting The Map Area More Precisely
Instead of relying on the map window to act as your area of interest, you can specify printing bounds (right click on the map) and move them to an exact position of your choice.
Final Notes
This 3D export function is by no means of the same quality as some other OSM 3D projects - you don't get any 3D objects apart from the terrain model, so don't expect to see any 3D buildings, trees etc. It is, however, a very simple tool to use (I hope) and it produces an output in a fairly open standard (COLLADA) which can then be tweaked with other software.
The next logical step would be to include the things like roads and buildings as actual 3D objects, but I will leave that for the future since my task list already very full with other features.
Please send me feedback if you find this feature useful (or indeed if you find it crappy). Since all this is beta, expect to find bugs. Also, if you're more of an expert in 3D field than me, a question for you: can you recommend any (preferably free) tool for raytracing which can consume COLLADA files generated by Maperitive?
