Hello Pierre,
I understand your point. The HDM rendering is work in progress, so
certainly the road rendering point have to be refined, but let me argue
a little bit on the current choices.
* first point, which is for me an important point: in my understanding
of the project, the HDM rendering targets *users* more than *OSM
editors*; what this means is that we should render the OSM infos, but
not necessarily the OSM *data scheme* for itself; this is a main
principle I'm working with in mind.
So for example in the road case, what in my opinion is important to
render is a clear *hierarchy* of the roads, something like: this one
sounds like a big, well maintained road, where this one is clearly small
and in bad conditions. But the fact that it's tagged as a primary road
in itself is a *OSM editor private information*.
* Road rendering is not just color. It's: color + border color, width,
border width, fill pattern, border pattern, name, optional shield.
The smoothness only alters the fill *pattern*, and so the color is
unchanged. Other example: the "narrow" tag only alter the width. On the
other hand, the surface, as you've seen, alters the color, but only the
color: all the other elements are kept as is. So in my opinion, but I
may be wrong, the level of the road in the hierarchy is still clear,
while it is also clear that this piece of road is not good.
* OSM has billions of informations. Creating a rendering means making
choices. Making choices in what to display or not, of course. But mostly
making choices in the hierarchy of the infos we want to display. And the
hard thing here is that the more one specific info is visible, the more
noise it creates for the other infos around. Believe me, it's hard to
find the limit between the info and the noise ;)
Thus, it's also important, in my point of view, to keep the color
spectrum as simple as possible. To be clear it's not possible to keep it
simple, but we should try hard. For this reason, in my opinion, it would
be a bad idea to try to create an "unpaved" new range of colors, like
for example: black red for normal primary road, and light red for
unpaved primary road. And so this is why I've chosen to use just one
color for unpaved road, keeping, as said before, all the other rendering
elements as is.
Anyway, I've heard and understood your concerns. I believe in my current
choices, as exposed here, but I will run a neurone in background task to
see what I can do better in surface road rendering :)
Yohan
On 06/21/2013 09:21 PM, Pierre Béland wrote:
Hi Yohan,
The CAP103 Team has done a great job with this HOT/HDM web rendering,
and your web rendering is just fantastic.
I would like to look more closely at how the rendering takes care of
Road classification vs surface and smoothness.
In your example below of rendering for road surface and smoothness, we
see how a section of a primary road that is unpaved is rendered. For
this section, the color for the primary road is grayed. This means that
the surface and smoothness color scheme and have preseance over the road
classification.
Would it be possible to render differently, without modification of the
color representing the road classification? This way, we would not loose
information about the road classification.
Pierre
------------------------------------------------------------------------
*De :* Yohan Boniface <[email protected]>
*À :* "[email protected]" <[email protected]>
*Envoyé le :* Jeudi 20 juin 2013 17h00
*Objet :* [HOT] HOT/HDM web rendering
Hi Hotties,
It's time to introduce the work being done on a humanitarian (HDM)
specific rendering.
TL;DR: http://umap.fluv.io/en/map/hdm-first-draft_728
The Humanitarian Data Model (HDM [1]) is the name of the HOT initiative
aiming to integrate humanitarian tagging scheme in OSM. As part of the
CAP103 project (Northern Haiti), we took the opportunity to refine it.
There are four components to this work:
- clean the HDM preset, ensure it is well integrated with OpenStreetMap
tagging habits [2]
- develop an extension of the HOT export tool which allows to transform
OSM tags into attributes values from reference existing schemas used by
humanitarian and development field workers
- work on a JOSM style to ease use of the preset [3]
- create a web rendering that highlight the HDM
I will now share with you the work in progress on the web rendering
step.
This web rendering has several goals:
One is simply to give editors a way to see the HDM OSM data without
having to use JOSM or a SQL console.
Another is to give humanitarian actors and developing countries a web
map that gives them the information they need, making OSM more and more
useful.
Finally, this is the occasion for HOT to have its own rendering, a nice
way to illustrate its work!
What does "highlight the HDM" means for a rendering? The main principle
is that each tag considered meaningful for the HDM should be rendered.
Here are some examples:
- road surface and smoothness are rendered (eg.
http://umap.fluv.io/en/map/hdm-first-draft_728#15/18.6665/-72.3048
<http://umap.fluv.io/en/map/hdm-first-draft_728#15/18.6665/-72.3048>where
a piece of the primary road is unpaved)
- water well are rendered (eg.
http://umap.fluv.io/en/map/hdm-first-draft_728#19/19.67901/-72.12665,
<http://umap.fluv.io/en/map/hdm-first-draft_728#19/19.67901/-72.12665,>
icons work in progress ;) )
- street lamps are rendered (same link)
- The craft tags are rendered
(http://umap.fluv.io/en/map/hdm-first-draft_728#19/19.67048/-72.12274)
- NGOs have their icons, for example:
http://umap.fluv.io/en/map/hdm-first-draft_728#19/19.75957/-72.20532
Also:
- terrain data is included (will be colorized:
http://umap.fluv.io/en/map/hdm-first-draft_728#11/19.5944/-72.1108)
- zoom until 20 is allowed: the goal is to enable mapping in very
detailed instances. For example, camps (fire hydrants are already
rendered:
http://umap.fluv.io/en/map/hdm-first-draft_728#20/19.76066/-72.20188
<http://umap.fluv.io/en/map/hdm-first-draft_728#20/19.76066/-72.20188>)
You can use this link to compare the HDM styling with the official OSM
rendering: http://compare.fluv.io/
All the work is of course open source, hosted on Github [4] (note that
the name is temporary, any thoughts on what the name of the rendering
should eventually officially be is welcome -- HOT Style, perhaps?).
It's
a TileMill/CartoCSS project.
Regarding the icons, we are using the Maki [5] project when possible,
plus the OCHA humanitarians icons [6] and Noun Project icons with
compliant license (CC0). Otherwise we design them. In each case, we
follow the Maki design rules [7].
As you can see, the actual demo tile service is focused on Haiti. This
is for two reasons: firstly, this work is part of the HOT current
haitian project (CAP103); secondly, the cleaned HDM has been first
tested/used on the Haitian Northern corridor. We will add more
countries
ASAP.
Thanks in advance for your feedback on the work. The preferred way for
giving feedback is to open issues on the Github page, but emails and
IRC
(#hot) are also good. Regardless of the source, we'd love feedback :)
Thanks!
Yohan, for the CAP103 team
[1] http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags
[2]
http://hot.openstreetmap.org/updates/2013-06-07_humanitarian_data_model_redux
[3] http://hot.openstreetmap.org/updates/hdmjosm
[4] https://github.com/hotosm/HDM-CartoCSS
[5] http://mapbox.com/maki/
[6] http://thenounproject.com/collections/ocha-humanitarian-icons/
[7] https://github.com/mapbox/maki/#notes-on-contributing
_______________________________________________
HOT mailing list
[email protected] <mailto:[email protected]>
http://lists.openstreetmap.org/listinfo/hot
_______________________________________________
HOT mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/hot
