Maybe (certainly?) not exactly. But I’m certain that “hey, we’re doing ‘this’ together…” (by the dozen, hundreds, even thousands), whatever ‘this’ might be, has the same excitement as 20 (well, 18+) years ago when OSM was in its early days.
We’ll have to tweak whatever toolchain “excites” and gives the feedback of “a map that blossoms” (with being ‘done’ with the street you just added). We’ll have to agree among ourselves whether it is addresses, or whatever, and where those data come from, and how they are entered (just so, following at least some rough blueprint) and what tools enable this.
But the motivation, even the excitement, will most certainly be there, especially when this is “done right.” This isn’t cheerleading, it is a kind of motivating force itself, a way to steer the map into its natural future.
Maybe it’s just me, but personally I’d take it as a complement if someone said my comments were aspirational. There’s nothing wrong with encouraging people to be successful. As I think someone else said further up in the discussion we are all here because we want the platform to succeed. We just have different ideas of how to do that and we express ourselves differently, that’s not a bad thing though. As I said, it’s a big enough tent for everyone. Cheerleading is just as important as honest criticism. I could probably be a little more encouraging myself sometimes. I tend to be more analytical about these things then other people though. There’s nothing wrong with that. Again, different strokes for different folks. There is no single “right” way to communicate. At least not outside of obvious incivility, but no one is acting that way in this discussion.
This is what fascinates me about OSM and also motivates me. Not regarding roads, but regarding tracks and paths. When I’m out by foot or bike, I still regularly find tracks and paths that haven’t been mapped yet or that are completely wrong. Even in Germany there are still forests that appear in OSM like an “empty map”.
I also know that many people use apps like Strava, Komoot, Outdooractive or other Hike/Bike-apps and often they even notice that a track or path is missing or wrong, but they have no idea that these app rely on OSM and that it would be super easy to fix these problems themselves.
If these apps could admit to themselves that OSM, by its very nature, can never be completely flawless or up to date, and they would promote the idea of OSM more to their users, that would certainly be a good way to attract new mappers as well. And maybe some of them would be motivated to participate for the same reasons I am.
Lots of words but other than dismissing my ideas, I’m not sure what this means. Would you like to suggest what you think new mappers are motivated by nowadays? I would argue it is the same as before. As in, people want to know that they are contributing in a way that is making a positive difference. This was easy to visualise in the past (blank map becomes map of roads). If we can find a good way to visualise it now, then we may have a better chance of recruiting and retaining new mappers.
A heads up: From this point on anything not tangentially related to one of the points of Steve’s plan will be exported to another thread. Any post that fits the mold of “my contribution is more reasonable and rational than yours for x reasons” will be flagged as off-topic and hidden. This type of talk does not contribute to this thread in any meaningful way. I have decided against splitting the thread as there are too many tangents to make that feasible.
I do think that is idea definitely worth considering. Here are few examples, which should be relatively easy to do, and not too annoying to use on defaultosm.org map (which is the important bit: Yes I know we have QA tools, which can show that already. And even settings which default to off on main osm.org map! But they are not shown there by default, which means while I’m looking for a route or browsing the map I won’t see it - and that I’d need to have to make dedicated effort “OK I am bored so I am going to do some QA on the map”, and obviously I do that few orders of magnitude less times than just visiting osm.org map. I suspect that is also why e.g. StreetComplete become popular - as it shows that missing data by default and allows to easily add it).
So the idea is to show that some data is missing by default, but not make it too much standing-out (like QA tools need to do!)
show OSM Notes by default. If there are notes, it is clear indication that something is wrong or missing, and should be fixed. Often when I’m looking at something else, I see them and solve them if they are easy, and sometimes it even becomes a small mapping session even if it was not intended to be!)
subtly render streets without names (and without noname=yes) differently. e.g. by having questionmarks like ??? stamped on them where name would go, or having them somewhat dimmed-out. That would not be too annoying (IMHO), and would indicate that such street misses name, and it should be fixed. (same ??? could be applied to water bodies without name etc).
subtly render highway=path without surface=* (and individual access) tags differently (as they are missing critical detail and it is so generic that is bordering unusable; e.g. they may be urban asphalt cycleways or barely passable on foot grass wood trails). E.g. by making them somewhat dimmer, and/or having bigger distance between dots/dashes). Should not be too annoying, but would indicate to the map user that they might be able to contribute there.
(I’d love if people would try consider those suggestions on their own merit, and give their opinion of pro and contra - regardless if the discussion that triggered them might’ve been inspired by person that they don’t like or whatever).
Well, should it be there for newcomers? It is complex, and complexity is IMHO not something you want to throw on newcomers, lest you scare them away:
Not only are newcomers not the target audience for list of all OSM software made (they’re having a plenty of problems grasping the difference between bitmap tiles and map objects!), but
it also highly time consuming (that list has 14 pages of software tools, with dozens of tools per page! Even if one sentence could tell you everything you wanted to know about that tool, it would be overwhelming even for experienced mappers, much less beginners),
and then there are political problems if you want to curate that list to get it down to more reasonable size (why recommend StreetComplete over EveryDoor for mobile map? or Vespucci? Or MapComplete? Who gets to decide? etc.)
Still, on main osm.org site, if you click on Help, there are guides for beginners right there. I don’t know how it could be made more discoverable except by replacing the main page osm.org with that information, and hiding the browsable map somewhere deeper (which would probably be way more annoying and confusing to newcomers who “just want the map” then actually useful to help them).
Perhaps that Help link could be styled in big friendly letters to stand out?
Or do you have suggestion how to make it more discoverable?
Why is this not more user friendly? As in, I see a long list but no indication of which of those tools are most useful for me, or even what does what.
Good question. Because nobody has done it? Perhaps you should ask the authors directly. Some grouping and especially oneliner description might help. I use mainly the Forum thread to find out about new version and keep up with new tools, though.
Otherwise, when searching for something specific, I’m more of a wiki fan (e.g. if I need something for QA, I’d look into Quality assurance - OpenStreetMap Wiki) - for me (who knows how to use ctrl-f and apostrophe in browser) that everything-in-one-html-page it is easier to use, and also allows for easier distribution of workload (everybody can add/update even a simple chunk of information easily themselves, and it is immediately visible to everyone, and people watching the page get update notifications too as a bonus).
That’s the point I’m trying to make. Don’t give me answers, instead think about how a newcomer will find what they need more easily.
Well, that was more general “you” for anyone asking themselves this question. But I get your point.
I agree. I might go a bit further and say that there should be some simple filtering available (e.g. recent Notes, Notes with photos). Highlighting Notes with Photos would encourage people to add photos now often which makes it so much easier to update the map.
There would also need to be an easy way for people to add me Notes with photos via their mobile phone.
Great question. Not the long unwieldy list that was linked to as that is too complex. We should pick out the best for newcomers and either link to those or make an effort to add those features to OSM.org. See my response to SK53 above about finding the right balance rather than creating a beast of a “one stop shop for all”.
This is where OSMF can help. It has its membership system and can use that as a form of democracy. It’s a potentially good selling point for membership - i.e. join as a member and have a say on what tools get expose on, or built in to, OSM.org
That’s exactly how to do it. Hiding the map is the wrong phrase though. You want to make it easy for someone to click through to the map, but at the same time show via a landing page that there’s more to OSM than the carto map.
Nice suggestion. A mock up would be great. Make it some sort of “call to action”.
P.s. thanks for the ideas. It’s made it a pleasure to respond to rather than feeling like I’m banging my head against a “none of this is new, let’s ignore” brick wall.
One issue that is more of a challenge: how do we make sure fresh contributors encountering QA tools early on fix the map and don’t just try to make the warnings go away?
@mnalis Effort-wise, it would be easier to use existing tooling for this kind of highlighting. If you want to put this stuff on the “main” map, you’d also first have to convince carto maintainers that this would be a good idea. Plus, it’s not really possible - you cannot fit everything into carto.
My counter suggestion here would be to have additional selectable layers that work just like the “map data layer”…
but instead of showing all data in uniform blue, each layer runs a certain predefined overpass query and the result is styled with MapCSS, just like it is done in overpass turbo.
And voilá, we have QA / ITO map kind of layers on osm.org.
Disclaimer: Now of course, that the returned overpass data can be styled with MapCSS is a feature of Overpass turbo, not of overpass, but it’s open source, so maybe that code could be copied.
The answer to that is careful selection of what “QA” you show and how you guide people to fixing it. QA that focusses on missing data (like streetcomplete, missing maxspeeds) is probably easier to manage than QA that attempts to identify map issues but often returns a lot of false positives.
I know exactly what I want: a framework to enable people to more easily create hyperlocal sites based on OpenStreetMap.
Bexhill OpenSteetMap and the two former sites created by Will Phillips (OSM-Nottingham and Evesham Mapped). These allowed thematic mapping which matched local interests and needs, but are not configurable, so similar sites need to be created de novo. Will retired his sites because the code was getting old and difficult to maintain.
The common elements were;
Use of leaflet
Geojson thematic layers from OSM (and potentially elsewhere)
Search. Will’s site allowed searching both OSM data and a large variety of other open data.
Numerous raster map layers, including thematic ones (with opacity and layering options)
Some kind of database back-end
If some of this functionality could be delivered via a non-programmatic configuration (e.g., something like JSON) of a black-box installation of components it might encourage more local sties to be created. We know that there is a desire for this sort of thing nearly everywhere: demonstrated by the map of pharmacies in Abidjan, and AddisMap, which may be the oldest local site based on OSM.
What you want would probably be best done by supporting non-global featured layers. This is mainly a UI issue that is solvable with existing technology fairly easily, but requires thought for defining what should happen when the user moves between locations and how to organize a menu.
Yes, it probably would (or using other style as default; I don’t think OSM is married to Carto 'till the death tears them apart; or at least it shouldn’t be). In any case, people would still first need to agree that change like is good idea and something they want.
Carto did recently implement different rendering for different surface tags on highway=residential/primary/secondary/..., so it is not unimaginable that they might add separate rendering for missing surface on highway=path, if community thinks it is a good idea.
The other idea of rendering ??? if there is no name nor noname=yes tags also doesn’t seem so hard to implement, or so objectionable (to me).
But the main question before proceeding is “do people think those are good ideas?”, or at least “do they object vehemently or not?”
TL:DR; it’s a long text, but since seems to not something new these focused local maps, instead of doing a hardcored one, I can make it based on reusables configuration, then the HTML/JavaScript/CSS be generated as result.
Could you @SK53 or others here design an example of such a configuration file? Then maybe I could get back a generated zip with the result.
While I haven’t yet developed all the moving parts of the frontend in some of your examples, I think this “black-box installation” could be delivered! The “hyperlocal” idea actually seems quite interesting (both for mappers or for talking with people to discuss previous added data or what’s still missing to improve) and also likely to not freeze the browser of the configuration request to load *everything* of some kind of PoI from that region.
I last week’s I noticed leaflet is quite handy (even have so many plugins) to create the background layers plus the multiple overlays, but for those not skilled with JavaScript (or even who is, but might have less time to keep things updated, so a configurable “setup and forget” would still be desirable) could be welcomed. So, yes, if you skip the “Some kind of database back-end”, to me the other parts seem viable (this also reduces vendor lock-in, because most of what would be on configuration file tend to be reusable) quite sooner.
Did you have a more specific configuration file for it? Others here could also give an opinion on this. From the implementation part, JSON may have one less requirement, however I think to make it a bit more friendly, you or others here could draft in YAML.
I guess that to make things simpler, the parts a preprocessor do not understand from the configuration file, it just skip it (or use default values), but for example as real world test case, at least:
background layers (ordered list)
overlay layers (ordered list)
The information here needs to be what is used to be converted to leaflet parameters. So, beyond how to fech the data, there’s typically the credits for that data source.
Also even pages of projects which user go directly (no home page or complex navigation menu) at bare minimum still relevant metadata for the generated HTML page (but could be later installable local app). I would suggest take as potential example the way Jekyll (its the same popularized by GitHub pages), but some basic information would be:
The center of the map; the initial zoom level
IETF language code (English = en), for accessibility
Page <title>
Page short description (think about search engines)
Contact information of who developed that map (how to render this might change by implementation, but the metadata is relevant)
[to comply with Overpass API (each server), Wikidata Query Service, etc] a name to be used when requesting data via backend request, e.g. the user agent, not merely a generic crawler user agent
(That’s it. The rest of the post is mostly early comments (which might explain how I way to use such configuration could work)
About how to potentially implement this (in my opinion at this moment)
The bare minimum could be to read background layers + overlay layers and generate the static HTML with all required parts to have a good enfouth page for users (I guess several other UI elements, generic search functionality of online services etc, could have opinionated defaults). With this in mind, I comfortable with several popular programming languages , but something such as PHP (which is easy to find even shared hosting, even if I lately use more Python and NodeJS) and cronjob (so some tasks could be done up-front, then cache the results) could help to not rely only on frontend. I mean, if it becomes too complicated to keep it online, the ideal audience will not use it.
In general, the leaflet expects overlay layers to already be in GeoJSON format (ok, we could create a new format, but better stay something more tools have support), however the configuration file could have some syntax sugar. This could both not merely accept GeoJSON ready to use , but also accept CSV (which after downloaded, could be converted to GeoJSON, maybe have some conventions of naming fields). If it becomes relevant I could do a different implementation just to help others prepare the data (e.g. convert XLSX to CSV). Similar logic could be applied for instructions which could be translated to Overpass or Wikidata. Like I said, in the worst case scenario, the user would need to pre-generate the GeoJSON layers, but if the generator reading the configuration could understand how they are created, then they could do this for the user.
Some kind of syntax sugar for both overpass queries or Wikidata could also exist. But to start, the most basic principle would be accept raw queries and some global variable defined on the configuration (or if passwords, since we want people to share these configurations, then the generators should also read secrets from other file or environment) be reusable on all other parts (like the user define a variable for represent the OSM relation id of the area which will contain the administrative boundary which the page will focus. For example, the overpass turbo supports some features, but the Overpass API needs raw query, so any syntax sugar needs to be written from scratch. Maybe in the worst case scenario, users take time and copy the raw query from the Overpass Turbo. I could try to explain how to generate queries for Wikidata which likely return relevant results.
Also, I would still need to improve proof of concept but if this thing becomes a bit more generic, since the actual number of layers or user configuration could be significant, then it could store user suggestions on browser local storage (I could do that, if feasible). I mean, if it’s allowed for the user to even add their own custom layers in addition to the default ones, then it’s likely that it will not be forgotten all the time (think about having later transparency! Or have multiple layers!). And if this becomes generic, it could also allow exporting the saved preferences, so even completely different domains for different focused cities could still reuse some preferences.
About editing capabilities, as soon as a user can download the raw dada of a GeoJSON layer, if the interface allows the user to change the data from the one loaded on by default on the webapp, then… we have a diff! And with a diff either the GeoJSON or a Level0 syntax text could be exported (and from level0, there’s ways to both use the Level0 from osmru or convert to something usable with JOSM. But anyway, my interest here would be something which the user could at least do some quick edit and save on their mobile browser, then later could decide what to do with that information. This alone might save time currently printing things on paper when doing surveys.
But I’m less likely to be interested in developing a full blow per-app authentication mechanism because it would take too much time documenting how to set up this, and the average user wanting to use simple hyper focused projects likely would benefit from creating more than one project page (each with focused city + loaded layers). Also, even more complex navigation between full project pages might be better let the user decide to do outside the configuration file. Likely if compared to a handcrafted custom app, we might need to cut down some features, make easier for software implementation reuse the configuration, and anyway, if user already not focused in a city, likely would be focused feature for large areas, so somewhat any web project would imply some sort of curation of what go or not there. If the user wants, just create another focused map + layers in another folder.
And yes, a very big use case would be data already not on OpenStreetMap. Maybe not even with latitude/longitude, but several data layers of things which miss being geolocated. So either on desktop or on mobile, the user could enable how many data layers would try to search (by address, by name, etc) then maybe could just copy that metadata but add more precise location, maybe fix some wrong asserted information which survey show be different. For example here in Brazil at the country level it is possible to have a dataset of all companies, so for example if a user is doing a survey and finds a shop, that shop address might even return a ref:vatin=* and other metadata such as phone contact.
Not sure if that’s what you SK53 had in mind, but if the design of the thing becomes simple enough, and even the schema of data layers to conflate (at least the important fields) could later also become predictable. So eventually instead of a per city website the data layers become predictable, some of these survey apps like Vespucci, StreetComplete, EveryDoor, etc could reuse the data layers themselves. However my initial experience externa data tend to have very poor location precision (often geocoders with not just imprecise location, but often can be outside a city) but at same time, some conflation key (like rev:vatin) should be necessary (maybe as part of the data layer schema, or the project configuration schema) because is important to know if the data already was in OpenStreetMap or not. Maybe the strategy could vary per world region, but here in Brazil often even the primary streets of smaller cities are full of commercial shops etc which have external data to match exact position, so if the user “lock” search in a street name (with some tolerance for misspellings), then the interface could by default sort the PoIs by addr:housenumber, so it become a survey route.
A leaflet centric approach by default is mobile and desktop friendly. But when on desktop, I think the user likely will need more the aerial imagery and can alt-tab between computer windows (have time to think), but on mobile might use both just the app plus some quick paper and pen annotations and also use search functionality a lot (because can already see things around, but have to march features to reduce need to write even long information like ref:vatin or other strong referential codes which could be used later to keep it updated. Since even the same user might swap between mobile and desktop, this explain why whatever is stored on browser local storage should be exportable/importable for things which already are not provided by the server side (which may be just static files re-generated by request or by crontab; but if user already updated either OpenStreetMap or the external dataset which create these layers, then it could stop show that Information).
But something to keep in mind, if the configuration themselves require the source of data be on some online URL (even if is to download a copy and cache locally) and suggest time unique ID for each dataset (which could be used on generated filenames) this make it more portable, because the entire thing could be rebuild on demand when the scripting part not find cached data not too outdated. By assuming source data is always outside it could be a way to somewhat let user use something like GSheets as storage engine for some data layers like PoIs which maybe miss to be geocoder (the GSheets API have an endpoint to export URLs as CSV) this could already reduce need of have a formal backend storage.
Like I said, suggestions on basic schema for background layers and overlays layers, plus one or more concrete examples could help me to draft something. Without any other suggestion, the implementation of this might be too hard coded by my use cases. There’s the vector tiles schema, which SK53 is proposing would be more a way to pack data layers per project (what I’m commenting here is how I could make an interface for it) on a configuration file.
