Hey @mmd,

That is a very important aspect as well. A current problem currently is a very low discoverability of these features. A clear section which at least points to some tools wouldn’t hurt thouh - most notably overpass, the wiki, a few consumer apps are highly needed and the most important ones.

@CjMalone: well, all these tools exists (see [https://hdyc.neis-one.org/]) - it’s just that they are hard to discover, exactly because the homepage is outdated.

TBH: I do think that there is a lack of vision what the frontpage has to do, and that part of the standstill is because of that. Whatever is changed, some group of people will either complain that ‘their’ favourite feature is gone or that their favourite idea should be implemented as well.

Use cases

For this, we should think about the multitude of use cases which wash up onto osm.org. I’ll list a few that I could think of on top of my head and are (I think) the most important ones - although I’m sure I missed quite a few:

users

• users wanting to ‘consume’ the map (search for places, get directions, get opening hours, …)
• users wanting to consume data (needing specific data items, needing a filter, bordering overpass-queries)
• users wanting a small snippet map into their website
• devs searching for a slippy map for their high-traffic website
• users searching for the ‘official’ OSM-app
• users searching for paper maps, either printed by themselves or by third parties

contributors

• people wanting to learn more about the project
• people wanting to learn how to contribute and get started
• contributors wanting to edit and validate their edits
• contributors wanting to get in touch in each other and other social aspects of the project

commercial contributors

• a small shop owner who wants to add their shop
• a small government body (think a small city administration) or NGO that wants to maintain a public data set on OSM

Technology

That vision should of course be combined with a technological solution which follows the OSM-spirit

• the stack should be transparent and easy to hack on
• the stack should be fully FLOSS and maintainable
• the usage policy should be clear
• all services should run on OSMF controlled hardware
• we should be welcoming to new contributors but at the same time not allow the codebase to become a spaghetti due to too many chefs in the kitchen
• promote new, cool technologies while remaining stable and offer a place for them to be tested. Why no routable tiles and peer-to-peer exchanged vector tiles, while still offering classical fallbacks if needed?

At last, there are quite some commercial projects as well. If OSM.org starts to offer vector tiles or geocoding for free, this will be a direct and free competitor to already existing (paid) services. IMHO, osm.org should support small projects with a usable free tier that is easily usable (say XXX map views/month) but give a clear guide on how to grow further.

A big overhaul

All this would imply a long and very tedious overhaul, not only of the technology but also of what we think the homepage should do. More space could be given to teach people a bit about OSM, while at the same time polishing the frontend, changing to a vector tile infrastructure, …

I had the same problem last year, so I started hacking on OsmAnd which has ski routing now as well.

For this, you have to enable the ‘Ski’-plugin, then enable the (by default) hidden ski profile in the profile management.

AFAIK not

@joost: thx, I’ve finally found time to fix the links.

Hi Thomas,

If you worry about colour-blind friendliness, I think user testing would work best. Find someone (colour-blindness is not that rare) and ask his opinion. (Although bumping the icon size definitively is a step in the good direction - thanks for considering it!)

If you edit something with iD and then save, you get a list of communication channels of the local community.

Try https://irc.openstreetmap.org/?chan=osm-fi and https://forum.openstreetmap.org/viewforum.php?id=15

Hey,

I have a small issue with the color code. Red for open notes and green for closed notes is not friendly for colorblind people; the small cross or checkmark help but I think they are not visible enough. That would make your work even better!

Thanks for the very usefull addition though, as I’m not colorblind it is already very useful for me.

Bienvenue! Il y a beaucoup de mappeur dans la Belgique, vous pouvez nous trouvez sur https://riot.im/app/#/room/#osmbe:matrix.org

Have a look at http://resultmaps.neis-one.org/oooc?zoom=14&lat=60.80916065&lon=21.41064225&layers=B0T

DWG is doing a good job. I don’t think they block if they don’t have to; and newbies messing up often respond well on changeset comments.

Hey Fernando,

Thanks for bringing this proposal into my attention. I’ve chimed in as well.

paving_pattern=* would indeed be better. However, then I’m still missing something to declare the type/size of the stone (e.g. square:50 instead of paving_stones:50, rectangular, …) It would also make the ‘top level’ -tag easier to use, as it has less options.

I’m a fan. Let’s write a wiki proposal for this… Just finding time

Consensus is mostly based on what I read on the wiki and wikipedia.

Most mappers indeed don’t know all these different kinds of paving stone. For those, I would propose to add a tag “paving_stone:type” or something similar. This way, the ‘surface=paving_stones’ still makes a sturdy database.

As I’m not an expert on paving_stones, I’d love a diary which explains the differences as well!

Smoothness can be somewhat subjective. Smoothness ‘good’ might mean that it’s good to drive with a mountainbike, but not rollerskates.

Or it might mean that the sett is freshly laid and still flat, whereas old sett tends to sink in the ground on parts…

That’s why I decided map the very measurable patterns.

And although I prefer the term sett over cobblestone, using cobblestone is still better than no information at allL.

Hey mygeomatic,

This should be possible; introduce a parameter as described, and use <select value="..." t="name" v="Street Name">

Hey,

I have no experience with BRouter. Perhaps drop them an email and ask about it?

Or perhaps just test it? Testing can be done relatively easily by hard blocking a road.

Also, I have no clue on how to encode height differences.

I have no idea, I only tried this with OsmAnd, as that is what I use…

Hey @naoliv

I’ve fixed the images! I knew they were broken, but it was late yesterday evening :p