[Osmf-talk] Alternative Strategic Plan

LeTopographeFou letopographefou at gmail.com
Sun May 14 20:13:28 UTC 2023


Hello Steve, all,

 From my point of view the better way to improve quality and coverage of 
OSM database is to focus on the usage more than on the data. If a data 
is being used (or is missing to be used), then it will be refreshed (or 
added). If the schema is clear, then editors, routers, users... will 
make sparks quicker. In that respect, I expect this project now to bring 
some more boost on the software ecosystem rather than on the completion 
of the data. One of the most famous example and troll is how the project 
is using itself those data. I love the map on the website from a 
graphical point of view because of its clarity and level of detail, but 
despite that I find this map nearly useless because you have very 
limited services offered compared to the potential of the database. And 
even those services are not fully end-user oriented, they are more proof 
of concepts. We are nerds of data when most of the people is looking for 
services.

Consequently, instead of having the completion as a top priority, I 
would focus on:

 1. Improving the database format/API to make it more accessible and
    powerful
     1. Separate the data (addr:*) from the meta data (review of an
        address). Data should stay free (use key and value you want) but
        meta data should be enforced IMHO.
     2. Handle cleanly some usages which are difficult to support today
        (e.g. Multiple values, translations...)
     3. Handle a clear lifecycle schema
         1. This might solve part of your concerns Steve because then we
            would be able to automatically associate to the data some
            confidence/freshness level
     4. Enforce usage of meta data (see previously)
     5. Provide some analytics around the data (e.g. I see a weird
        key+value on N objects, I want to understand if this is due to a
        single user, or a single SW (bug?))
     6. Offer tools to extend/filter the API results on request (note
        that this might require some third party databases, which means
        some license questions, also this would prevent from
        reincorporating them into the DB), for example:
         1. Roads are flagged with maxspeed=FR:urban, offer to deliver
            as it is or as maxspeed=50 or with some kind of alias table
            ready to be used
         2. Some shops contain PH in their opening_hours, offer to
            expend them to the real dates for the year to come or
            provide some kind of list of public holidays at this
            specific location
         3. Some items contains wikidata keys, offer to expend them to
            include additional data from this external database such as
            altitude, names in different languages...
         4. Say that there is a picnic area... When extracting data,
            have a flag to associate or not an independent set of extra
            deduced attributes based on the POI within this area such as
            "toilet=yes/no", "fireplace=3"...
 2. Having more services available on the website, either by developing
    them or integrating them (which doesn't mean to phagocyte them)
     1. Foster the integration of more maps to showcase the diversity
        and stimulate the completeness of the data (for car, for e-cars,
        for bikes, for hikers, nautical, infrastructures, culture,
        geopolitical...)
     2. Ideally, having a reduced set of maps but with layers and
        ability to select the language
     3. Being able to interact with the map to see the data (to know if
        it is fresh, you need to see them in an easy and readable way)
     4. For this it might require a structured way of proposing and
        integrating a third-party
 3. Defining approved presets in a structured way
     1. To propose an already built list of presets that can be parsed
        and used in a SW
     2. To propose names in different languages without the need to have
        its own translations (that can also be misleading if not
        aligned, see differences between iD, JOSM and the Wiki)
     3. For editors (iD, JOSM...) to suggest recommended tags or
        discourage others

Those ideas are on my wish-list for years now but with no time or energy 
to implement them or even promote them. However if some people show 
interest to some of them, please ping and I will see how and if I can help.

Cheers,

LeTopographeFou

Le 13/05/2023 à 17:38, Steve Coast a écrit :
>
> Dear all
>
> We formed OSMF to take care of the map. Let’s reset and focus on that 
> with a strategic plan by the mappers for the mappers:
>
> 1.The website will focus on completing the map. The map currently 
> shows the “best” view of the map, it will be changed via voluntary or 
> paid efforts to show the “worst” view of the map to encourage 
> completion, like in the beginning when it was blank, and it led to 
> huge efforts to fill the map in:
>
> a.We will decide what the main thing to complete is. For example, if 
> we decide it’s address data then we will do the following:
>
> i.OSM will only render roads with a new tag “addr:complete", where 
> mappers manually will have to mark roads as address complete. This 
> will immediately make the map go very blank and create a large global 
> project to finish addressing, which is the main thing missing in OSM.
>
> ii.Once complete, we will take similar steps to map, for example, PoIs 
> and only show roads will all PoIs added.
>
> b.OSM will only render features newer than 24 months to encourage 
> refreshing and revisiting. A tag “feature:verified_2023” or equivalent 
> will be used to do this, along with the last edit date of the feature.
>
> c.Map notes will be turned on by default.
>
> d.Social and map quality features will be built in to osm.org which 
> will drive engagement and mapping towards completion, for example 
> alerting users to edits or routing problems near where they edit.[2]
>
> e.Leaderboards of editors, countries, states, regions and counties 
> will be front and center to encourage editing, for example percentage 
> of “addr:complete” roads per country.
>
> 2.Funding will focus on completing the map:
>
> a.By having a clear metrics-based plan above we can seek funding to 
> build specific tools and features towards map completion.
>
> b.A paid “OpenStreetMap Approved” program will standardize corporate 
> membership by certifying a company uses OSM data in a way that 
> respects the license and community.
>
> c.A certified version of OSM will be released quarterly that has been 
> semi-automatically checked for validity and correctness. Paid 
> corporate members can be involved in the process.
>
> d.OSM conferences and local chapters will pay OSMF a small fee per 
> attendee or member and in exchange also be “OpenStreetMap Approved”, 
> once the board is shown to be effective.
>
> 3.The board will focus on completing the map:
>
> a.Reduce the board size and require regional representation.
>
> b.Board members must make a public financial and time commitment.
>
> c.The board will build completion metrics for the map, by using 
> existing tools and working with companies who already have many tools, 
> and engaging with the community. These will be the main agenda of the 
> board meetings.
>
> d.All discretionary funding will go to projects and community members 
> who build credible plans to help complete the map.
>
> If this is interesting, I’d love feedback. We can run some BoF 
> sessions at SOTM US, EU and Africa in July, November and December. 
> Then SOTM Asia when it is confirmed.
>
> Best
>
> Steve
>
>
> _______________________________________________
> osmf-talk mailing list
> osmf-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osmf-talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20230514/29e4f517/attachment.htm>


More information about the osmf-talk mailing list