Re: OpenStreetMap Cartographic: A client-side rendered OpenStreetMap Carto

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: OpenStreetMap Cartographic: A client-side rendered OpenStreetMap Carto

SandorS

Not sure I understand enough well the many technologies you want to mix here, especially the essential once like tilekiln, vectortiles, CartoCSS stylesheet … where you are the author/maintainer and where “… not provided a project description”. Yet, I do understand, you intend to develop a vector tiles based server-(mobile)client cartographic service using the OSM source data. Being there in a really long time and having developed several innovative related technologies, I will mention some traps and issues you will meet on your way “...at zoom 0 and am working my way down”. Being aware of them you may save lot of time and effort. Besides, some of the suggestions might help you to really make a difference.

If you jump over the data preparation (you may call it pre-processing) initial phase of the development, you will not reach further than the existing OSM maps. Lots of the data anomalies in the source will inevitably limit the quality and the efficiency of your further work on scale levels (vs zoom levels) generation, data generalisation, vector tiling, rendering on the client side, and so on. Among huge number of these let me mention just a few: object fragmentation, object replication (exact, almost, part of it...), missing parts or objects (fragments), unsynchronized objects in different classes, spiky start-end line connections, illogical/meaningless objects and object presentations, and so on. Without a robust preparation the consequences may be quite serious both visually and functionally (even leading to useless maps), especially in the vector map/making. Of cause, you/anyone working with vector map-making, may find large number of examples to illustrate the mentioned anomalies and the consequences. A robust preparation process may remove/correct most of the (well over hundred thousands) mentioned anomalies.

The next phase, the server data preparation you will probably start with the scale levels generation and end with the pre-tiling process. Besides the point object types, you have probably selected some 80 to 120 area and line modelled types that provide input to a very reach base-map. The scale levels numbering and the scale factor values should definitely not follow those defined by the OSM raster zoom levels (though, formally they can). Consider the data size criteria after scaling to a scale level. To (radically) reduce the data size in the level you will inevitably want to apply a cartographic generalisation. Consider a model that never causes fragmentation/brakes on solid objects (one of the worst consequences). The process should remove very small objects and tiny sections and perform vector smoothing (reduction). Consider dynamic criterion based smoothing (on fine details short, while on smooth details long vectors). Here you may want to do corrections on parallel roads, self-crossing polygons, inner-outer polygon crossings and so on. But this depends whether you use an old fashion or a modern topology base rendering algorithm on the client side.

If the object class scale level is not empty, you would probably run a tiling process. If you want an attractive arbitrary (vs. “continuous”) scaling and rotation, object layers switch on/of, z-moving, transparency, anchoring, panning… consider pre-tiling per object layers instead of all object types per tile. If you want a really innovative vector server-client system consider a multi-tiling based on-the-fly tiling where the final tiles to transmit are created according to the individual client request parameters. This model might provide unparalleled efficiency and flexibility. There is no need for extended tiles, unclipped objects, caching (yet, clients may have individual strategies) and so on.

On the client side the only thing should remain to do is the anti-alias rendering. As mentioned, if on-the-fly multi-tiling is used, everything is done on the server except the rendering. Besides the default stiles, consider allowing users to define arbitrary stiles. For the line objects, you may find highly efficient thick line renderers (you know, the thick line paradigm) where the border lines, stilling… you get for free and the speed is practically the same as for the thin (one pixel) lines. For the area fill, consider a topology (inner, border and outer points) based algorithm. As a role, such models tolerate self-closings, touching… even inner polygons crossing outers. Again, the arbitrary fill styling you get with these for free. Finally, I warmly suggest considering use of image based fonts for labelling/texts instead of classical (built in) fonts. Though, you can not render large characters, the size of an image font is hundreds of times smaller compared to the built in vector font(s). From the same source you can create arbitrary character sets and you have simple and full control of all character and text parameters. You can even have a dynamic labelling (e.g. the street name is moving to the left when panning to the right).

There are huge number of missing details at this level of communication. For you and other vector based GIS and map-making enthusiasts I am freely available to demonstrate, discus, present… eventually help where I can using other communication channels.

Regards, Sandor.

 

 

Sent from Mail for Windows 10

 


_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenStreetMap Cartographic: A client-side rendered OpenStreetMap Carto

SandorS

            Not sure I understand enough well the many technologies you want to mix here, especially the essential once like tilekiln, vectortiles, CartoCSS stylesheet … where you are the author/maintainer and where “… not provided a project description”. Yet, I do understand, you intend to develop a vector tiles based server-(mobile)client cartographic service using the OSM source data. Being there in a really long time and having developed several innovative related technologies, I will mention some traps and issues you will meet on your way “...at zoom 0 and am working my way down”. Being aware of them you may save lot of time and effort. Besides, some of the suggestions might help you to really make a difference.

            If you jump over the data preparation (you may call it pre-processing) initial phase of the development, you will not reach further than the existing OSM maps. Lots of the data anomalies in the source will inevitably limit the quality and the efficiency of your further work on scale levels (vs zoom levels) generation, data generalisation, vector tiling, rendering on the client side, and so on. Among huge number of these let me mention just a few: object fragmentation, object replication (exact, almost, part of it...), missing parts or objects (fragments), unsynchronized objects in different classes, spiky start-end line connections, illogical/meaningless objects and object presentations, and so on. Without a robust preparation the consequences may be quite serious both visually and functionally (even leading to useless maps), especially in the vector map/making. Of cause, you/anyone working with vector map-making, may find large number of examples to illustrate the mentioned anomalies and the consequences. A robust preparation process may remove/correct most of the (well over hundred thousands) mentioned anomalies.

            The next phase, the server data preparation you will probably start with the scale levels generation and end with the pre-tiling process. Besides the point object types, you have probably selected some 80 to 120 area and line modelled types that provide input to a very reach base-map. The scale levels numbering and the scale factor values should definitely not follow those defined by the OSM raster zoom levels (though, formally they can). Consider the data size criteria after scaling to a scale level. To (radically) reduce the data size in the level you will inevitably want to apply a cartographic generalisation. Consider a model that never causes fragmentation/brakes on solid objects (one of the worst consequences). The process should remove very small objects and tiny sections and perform vector smoothing (reduction). Consider dynamic criterion based smoothing (on fine details short, while on smooth details long vectors). Here you may want to do corrections on parallel roads, self-crossing polygons, inner-outer polygon crossings and so on. But this depends whether you use an old fashion or a modern topology base rendering algorithm on the client side.

If the object class scale level is not empty, you would probably run a tiling process. If you want an attractive arbitrary (vs. “continuous”) scaling and rotation, object layers switch on/of, z-moving, transparency, anchoring, panning… consider pre-tiling per object layers instead of all object types per tile. If you want a really innovative vector server-client system consider a multi-tiling based on-the-fly tiling where the final tiles to transmit are created according to the individual client request parameters. This model might provide unparalleled efficiency and flexibility. There is no need for extended tiles, unclipped objects, caching (yet, clients may have individual strategies) and so on.

            On the client side the only thing should remain to do is the anti-alias rendering. As mentioned, if on-the-fly multi-tiling is used, everything is done on the server except the rendering. Besides the default stiles, consider allowing users to define arbitrary stiles. For the line objects, you may find highly efficient thick line renderers (you know the thick line paradigm) where the border lines, stilling… you get for free and the speed is practically the same as for the thin (one pixel) lines. For the area fill, consider a topology (inner, border and outer points) based algorithm. As a role, such models tolerate self-closings, touching… even inner polygons crossing outers. Again, the arbitrary fill styling you get with these for free. Finally, I warmly suggest considering use of image based fonts for labelling/texts instead of classical (built in) fonts. Though, you can not render large characters, the size of an image font is hundreds of times smaller compared to the built in vector font(s). From the same source you can create arbitrary character sets and you have simple and full control of all character and text parameters. You can even have a dynamic labelling (e.g. the street name is moving to the left when panning to the right).

            There is huge number of missing details at this level of communication. For you and other vector based GIS and map-making enthusiasts I am freely available to demonstrate, discus, present… eventually help where I can using other communication channels.

            Regards, Sandor.

 

 

Sent from Mail for Windows 10

 


_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev