Document design goals

[matkoniecz]

It would be useful to documents design goals of this project. "keep it as simple as possible, this is not supposed to be replacement for Google Maps with its integrated services" is sometimes repeated - but currently I see no way to check whatever it is true and up to date (I remember/misremember it as an old explanation for why there is no route finding on OSM website).

I thought about something short, similar to https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md

In my case I considered "adding opening hours as an additional selectable overlay on OSM website" (basically, adding http://ypid.de/~osm/ as overlay working similar to "Map Data" overlay) - but I am not sure how I should check whatever something like that would be even considered as a valid addition.

At this moment the best solutions is to open issue requesting such feature (like #706) waiting about week and check whatever one of main developers commented that it is a bad idea. In case of lack of negative comments assume that maybe it is a good idea and start coding with hope that finished work will not be rejected as mismatching overall goals. This would be slower, more prone to mistakes and would result in some completely pointless issues.

In case that something like that exists - adding link to it in https://github.com/openstreetmap/openstreetmap-website/blob/master/CONTRIBUTING.md would be a good idea.

[kocio-pl]

"keep it as simple as possible, this is not supposed to be replacement for Google Maps with its integrated services" is sometimes repeated - but currently I see no way to check whatever it is true and up to date

I also wouldn't know what "as simple as possible" really means. We're halfway between pure minimum (one static layer with some links) and "full" OSM-related stack (almost no overlays or personalization like UMap), and I would say it's already closer to the latter than former, so it may be 3/4 or 8/10. We have 2 search engines, 2 editors, 3 routing engines, 5 map layers, object explorer, notes overlay and exporting mode - for me it's a lot of things above the bare map, but the UI design is still not overloaded, so I'm confused what would it mean. Integration and feature richness is not an enemy of simplicity of use.

[tomhughes]

Those things are all there because they help mappers though... and in some cases I would like to trim them down (getting rid of all the extra search engines for example - they were needed when our data was less complete but not so much now).

[kocio-pl]

This brings another important question on the table: where is the portal for end users then? Or maybe OSM is purely "mapping for mappers" effort (which is not the case with lack of rendering many items on osm-carto)?

[kocio-pl]

This thread on Talk list proves that it's just a lack of horsepower to serve everybody, so we're concentrating on mappers, because it helps growing dataset and making it better.

I guess it means there is no general veto for additional features given that they are light enough, we have more resources or it's just integrating useful and predictable external service.

[tomhughes]

I'm not sure what the opinion of random people on talk has to do with anything?

[kocio-pl]

I consider Talk not "a random people list", but rather an important channel of communication for OSM community, where one can discuss some general issues - doesn't it? And OSM.org is this community's portal - or am I wrong?

Of course this does not impose any decisions on this (sub)project and it was just my conclusions from this thread, nothing more. But suggesting it has "nothing to do with anything" is at least surprising for me: are we that disconnected in OSM or maybe I'm unaware of some underpinnings? I hope for the latter.

[tomhughes]

Well I'm pretty sure you could suggest anything you'd like on talk and find at least half a dozen people to agree with you. Neither that, nor having infinite resources, necessarily means something could or should be done.

[kocio-pl]

English is not my mother tongue, but I'm pretty sure "I guess it means" is not the same as "it necessarily means", so you seem to be attacking a straw man (= opposing something I haven't said or meant). I don't like to guess and prefer to know and there's nothing to disagree - I just don't feel your comments helped me understand anything better.

Leaving aside word games, I support @matkoniecz motion to describe design goals of this portal and I'd like to ask:

1. What "could or should be done" within the scope of this portal?
2. (helper question:) Who is assumed to set these goals?

Please don't treat me like an intruder on someone else's yard demanding anything - it's not my intention and I don't feel like being one. I'm just a community member which has his own agenda (as everybody) and tries to find some important answers.

[matkoniecz]

Those things are all there because they help mappers though... and in some cases I would like to trim them down

So only things useful for mappers should be proposed, but like in case of routing engine it does not mean that new features should not appear?

Would it be OK to (for example) add new overlay (in addition to notes & data) displaying opening_hours data?

[d1g]

(getting rid of all the extra search engines for example - they were needed when our data was less complete but not so much now).

We don't need simplistic geocoders like GeoNames. You may safely remove it. Not only it is not useful today for a reasons @tomhughes mentioned, but also it cofuses mappers by returning fake or erroneous results from GeoNames database rather than clean and error-free OSM db. I'm not sure if it is applies to implementation details, but idea is the same: OSM>GeoNames is almost any aspect today.

Note that we have 2 geocoders:
openstreetmap.ru since 2012 http://forum.openstreetmap.org/viewtopic.php?id=14295 - Nominatim is THAT bad at Russian language and russian tagging schemes.
gazetteer since 2014 https://github.com/kiselev-dv/gazetteer - may provide superior results compared to Nominatim

3D layer would be nice. Some newcomers state than they cannot use ANY of 4 osm.org layers because "they are flat". The only answer I can give to them is "useinsanelylongservicenameinenglish.org".

"MapSurfer.net" may work as simple 3D layer (while it may be not fine tuned visually, it's feature-rich)
https://github.com/ErshKUS/OpenStreetMap.ru/blob/00bce5ac093d58ae694715cb39be7a77faa5d4bf/www/js/page.map/osm.layers.js#L9

Why do we need features other than "single flat map" for anyone wondering

POI catalog https://github.com/ErshKUS/osmCatalog is still missing (openstreetmap.ru is 3-4 years ahead of osm.org here). I STILL hear statements "man, OSM is just a map"... I'd rather keep at least one good routing and at least basic POI catalogue so stop people making false statements about OSM and wrong decisions in their life.

Think about osm.org as visit card or demo what OSM can do.

We can highlight some services: we don't need every 100+ flatmap service but we need a few of them; we don't need every single router, but some of them. Unfortunately not all services can provide quality in every aspect and worldwide coverage/user traffic.