Foundation/AGM2022/Election to Board/Answers and manifestos/Q07 OSMF and Technical direction

From OpenStreetMap Wiki
Jump to navigation Jump to search

OSMF ... and Technical direction

In 2022, an OSMF working group commissioned a study to examine the OSM data model. That study highlighted a long list of identified issues, possible solutions, and a phased strategy for implementing changes.

Do you have any views whether our 13-year old core infrastructure (API, data model) still meets the needs of OSM users today and into the future? If no, what do you intend to do to make sure that OSM remains technically relevant into the future if elected?

Do you think this should be entirely up to working group(s) or should you get involved as a board member? If so, what do you consider the proper way of going about it?

Daniela Waltersdorfer J. - Q07 OSMF ... and Technical direction

First and foremost, I'd like to highlight a key few sentences from the paper: "While writing this paper a lot of topics were suggested that it could address. But much of this is out of scope. This is about the OSM data model, the nodes, ways, relations, tags, changesets. It is not about anything user facing, it is not about tagging, it is not about the OSM website. The API is only in scope so far as it talks about those OSM data model issues. Other parts of the API, such as user management, notes, GPX upload, etc. are not in scope. (That’s why this is paper is not called “Ideas for API 0.7”1 or something like that).

As I mentioned earlier, I am not a programmer or software developer, so some of the technical components and potential guidance offered here is something out of my area of expertise. On a personal note, I liked the idea of looking into cleaning some of the untagged nodes... but would like to educate myself more about that before making any recommendations. Again, I'm not an technical expert. Being that said, as an member of the OSMF, I think my role would be to help the Foundation open up channels of communications to learn and record what our different chapters think will work best for them, and working with them to come up with the best solutions based on the paper's recommendations. OSM Local Chapters represent our global community, and since they are our prime users, we should collaborate with and listen to them to meet their needs now and in the coming future.

Arnalie Vicario - Q07 OSMF ... and Technical direction

I would be supportive of the Engineering WG to test and try out the suggested improvements and next steps as outlined in the study. As OSM is a community project, I highly value the recommendation to conduct community consultations - the next question is: Who will be consulted? We need to ensure that all perspectives are captured.

Personally, having a GIS background, I am accustomed to the common data model/elements: Points, Lines and Polygons. To share, in previous community training, I needed to familiarize myself with the terminologies of the current OSM Data Model: Nodes, Ways, Relations and Tags, then to translate it into simpler terms that communities can understand and relate to by giving examples. OSM iD editor takes this into account (polygon as area).

Włodzimierz Bartczak - Q07 OSMF ... and Technical direction

I have been following the discussion around both the API and the data model. I also read Jochen's paper as soon as it was published. The data model we use shares responsibility for the success of the OSM project, in particular its flexibility and simplicity. Any attempt to change it must be done slowly and in a very deliberate way. Setting up a working group that will have to cooperate with the OSMF and the community is the only way. The consequences of making a mistake in this area could be disastrous for the project.

In the case of the API, the issue is, in my view, somewhat simpler but more urgent. In the 13 years since the last significant change, OSM has changed a lot, the complexity of the data available in the project has increased dramatically. Interior mapping, 3D tags, the popularity of the project and therefore the amount of vandalism. The use of data has also increased. Jochen's study does not exhaust all the problems. In the discussions I took part in, there were often questions about the moderation of more key objects and references to solutions found in Wikipedia. Also, if we decide to implement tagging standards, a rebuilding of the API will be necessary, as we cannot rely on solutions in the software that are only a suggestion.

Ariel Kadouri - Q07 OSMF ... and Technical direction

I would like to thank the board for commissioning the data model study as well as Jochen for the work put into the study, the talks at SoTM 2018, 2022 and the community engagement via GitHub, mailing lists, and elsewhere online.

This is a massive effort but it does address issues with the current data model. I do not believe the board should be involved at the technical level but rather provide support to the working groups and community involved in determining the course to take. As outlined in the study, this project will require resources and staffing (project management, technical leadership, community relations, financial support). I believe the board should be involved in raising funds and facilitating the hiring of those positions, as well as hosting and directing conversations that are difficult for the community to conclude on their own. This effort will require at least a single board member champion, if not multiple.

Victor N.Sunday - Q07 OSMF ... and Technical direction

Christian Shadrack - Q07 OSMF ... and Technical direction

No, I think it's imperative to adapt as things progress and allow users to find each other. Every year there are new things and it is really necessary to update and move forward together with the elements. If I am elected, it will be with pleasure and very willing to participate and give a hand to the team in charge. It is together that we can build a strong OSM nation. As I said before, the participation and the intervention in the different working groups will allow to know the evolutions of the moment and to collect the necessary information for the different updates. For this you just need to be willing and ready to participate as much as possible.

The participation and the fact of being available allowed me once to build a whole database for humanitarian actions.

Sarah Hoffmann - Q07 OSMF ... and Technical direction

The API and data model have served us well in the last 13 years. But there are some cracks that start appearing. They are not so much of a problem today but they might become serious issues in the future if we don't tend to them. The times are long gone where a small core group of people could get together on a weekend and fix issues around the core. There are so many parties now that have a vested interest or are affected by changes. To make things worse, we don't even agree on what the real cracks are and what is just a little scratch. It is important to keep discussing and analyzing. Then we can figure out what is important and what is doable. A working group is just fine for such a task. The board can encourage the EWG not to drop the ball on the topic, independently of whether they want to follow what was laid out in the study or continue to investigate a different strategy.

Full disclosure: the mentioned study was done by my spouse, so I did have some insight into its making.

Logan McGovern - Q07 OSMF ... and Technical direction

I do have concerns about the ability of the data model to support the needs of users farther off in the future. From my understanding, there are a variety of changes that could be made the data model to increase the efficiency. I do think that most of the changes Jochen Topf advocates for are positive such as stable ids! However, I am agnostic about the addition of a third data type to the model for polygons. I am not against invoking a special session where opponents and proponents are given the chance to debate the necessity of various changes to the data model before the OSMF board, and then the board could vote to endorse certain changes, but merely endorse without obligating any specific action from the working groups. I am leery of dictating to the working groups. If it's a unanimous vote then I think that could possibly be binding, obliging the working groups to work towards a particular set of goals.

Arun Ganesh - Q07 OSMF ... and Technical direction

The growth of businesses powered with OSM data is a great sign that in spite of the issues highlighted in the study, they are currently not a blocker for data users. The study is very valuable and there is no denying there are growing technical pains, but my impression is that it affects a very narrow audience in a practical way to require immediate action.

As an example an area type can unlock a lot of data value and reduce future errors, but with evolving AI/ML technology this may cease to be an issue in the near future for data users.

The responsibility of the board should be to get more visibility for the study among a diverse technical audience and arrive at a concrete list of which issues would make mapping more easy, unlock the most data value and reduce operational costs. Without doubt we should be doing more of such technical reviews and be encouraging more academic participation in such topics to stay relevant.

Mateusz Konieczny - Q07 OSMF ... and Technical direction

API, data model meets our needs but can be improved to make things better.

For example, a dedicated area data type would save an enormous amount of confusion, but OSM will survive also without it.

OSMF board involvement would make sense in case of large scale changes or ones where the costs involved are a substantial part of the OSMF budget.

I am pretty sure that we need to act to handle GDPR (see the answer to the question #3). And for the last four years, it was not progressing and was declared by OWG to not be a priority at all, with no work planned on it

If something needs to be done an intervention by the OSMF board would be needed.

Craig Allan - Q07 OSMF ... and Technical direction

Do you have an views whether our 13-year old core infrastructure (API, data model) still meets the needs of OSM users today and into the future? If no, what do you intend to do to make sure that OSM remains technically relevant into the future if elected? Do you think this should be entirely up to working group(s) or should you get involved as a board member? If so, what do you consider the proper way of going about it?

Preface:

My belief is that the state of the software underlying OSM's operations, while open source, is generally under-reported to the Board in any formal report. This shortfall is likely related to the apparent lack of volunteers for communicating about technical work.

Meeting the needs of OSM users today and into the future:

Jochen Topf was engaged to look at the OSM data model and he identified changes to simplify processing OSM data. I do love clean, logical, elegant data structures, so maybe Jochen has a point.

Steve Coast wrote a dissenting blog on keeping the data structure as simple as possible and letting the computers do the work of simplifying the data. I am a big fan of keeping things simple for humans and letting computers do all the work, so Steve may have a point.

I'd like to see if OSMF can reconcile both positions. Can we improve the user experience of our mappers and simultaneously improve the data processing environment for our system developers and for our data users? Both are desirable and very likely both are attainable if the resources can be found.

I will study Jochen's 40 page technical report very closely and learn a lot more about the OSM systems he and Steve are discussing. The Board will have to make a decision on implementation, and I'd like to be a well informed part of that discussion.

  1. Jochen's Blog on this task HERE
  2. Jochen's report on the Data Model HERE
  3. Steve's blog promoting simple Data Models HERE
Ensure OSM remains technically relevant into the future:

I'm keen on having up to date, reliable and readily maintainable IT assets for OSM. To make sure that OSM is 'technically relevant' I will be a committed member of a collective. Software development and maintenance as well as hardware upgrades and maintenance are a matter for negotiations between some subset of the following groups: the Board, the Engineering Working Group, Operations Working Group, SysAdmins Group and our Site Reliability Engineer. This may seem a big and unwieldy group, but I have long experience in guiding big unwieldy government groups into making action plans.

Be aware that the working groups are autonomous, and tend to defend that autonomy with resolve, so the negotiation is one between equals acting together in the interests of the organisation. I'd like to be involved in such negotiations to learn more about our system, to finally meet the people involved and to work with them to remove all possible obstacles to 'technical relevance'.

Should I get involved as a board member and what is the proper way of doing it?

Yes, as a Board member I would definitely seek to engage with Working Groups. Working Groups are autonomous but, in good faith and in the interests of OSM, the Board and the WGs will mostly co-operate. So 'getting involved' is done by following protocols and the first step is to contact the Working Group chair and request a discussion.


OSM Foundation's board election 2022: official questions

All board candidates' manifestos

2022 OpenStreetMap Foundation's: Board election - Voting information and instructions - Annual General Meeting

v · d · e
Annual General Meetings of the OpenStreetMap Foundation
Board Elections
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Foundation/AGM2022/Election_to_Board/Answers_and_manifestos/Q07_OSMF_and_Technical_direction&oldid=2445072"