-
Notifications
You must be signed in to change notification settings - Fork 210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Announcing Vector Tile 3.0 Specification Development #103
Comments
I have an interest in updates to the spec, particularly around storage of different types of data. If the spec WG was not all Mapbox or dominated by one company, I would be interested in contributing. |
Note: https://github.com/orgs/mapbox/teams/vt-working-group returns a 404 error. |
@pnorman from the
|
There is no activity since April 2018 here at "Vector Tile 3.0 Specification Development" and in the project: https://github.com/mapbox/vector-tile-spec/projects/1 . Has Vector Tile 3.0 Specification Development been stopped or abandoned? |
At Mapbox we have been amazed by the success of our Vector Tile specification and have greatly enjoyed seeing the many different technologies that have grown around it since our initial public release of a specification almost 4 years ago. It has been quite a journey and we have learned so much along the way. We started the last change to the specification approximately 2.5 years ago to make sure that the development community developed a truly interchangeable format, but the time has come to consider further updates to the specification.
I am very much excited to announce that we are now beginning work on Mapbox Vector Tile Specification version 3 (VT3).
Why Now?
In the past 4 years since the original vector tile specification was released many changes have been proposed for the Vector Tile format, many of which have been collected as issues of this repository. These proposed changes have been driven by many different causes and have highlighted many different needs of the specification going forward. We now believe that this is the right time to start experimenting with these different proposed changes.
What Will Change?
In our last update of the specification we purposefully held back from any major changes to the format and focused instead on solidifying the original design and documenting what was not obvious prior. This meant that many great ideas we simply saved for a later date instead of considering for v2 of the specification. For VT3 we are opening the possibility of breaking changes to the specification.
North Star
There are somethings about Vector Tiles that will never change. They will always be designed to:
How will this happen?
We will be reviewing internally at Mapbox different ideas that we have been considering over the years in various repositories and will begin to migrate these ideas to issues in this repository. Those external to Mapbox are welcome to join in the process as we will be attempting to do as much as we can in the open and welcome others.
Once each issue has been added, I will add it as quickly as possible to the "Proposal Tracking Issue" that I will be opening shortly. Each proposal will be given one of the following status, which it could likely progress through:
The migration of issues between these steps will be controlled by the Vector Tile Working Group (@mapbox/vt-working-group) at Mapbox. The Working Group will be responsible for reviewing specific ideas, prototypes, and issues to make sure that the Vector Tile specification is well suited not only for Mapbox but also for other developers and applications using the specification. The Working Group will be responsible for what is accepted into the specification and what is not.
I will be acting as "Lead Author" during this development process. My responsibilities will be to support the Working Group by providing coordination of different efforts within the Working Group. Additionally, I will be focused on supporting any contribution from outside Mapbox. Finally, I will also be responsible for collecting accepted technical changes into a final edited specification, which we will then present for a final review.
Technical Design
This is the first step a proposal will involve. It is the discovery phase of the process and often starts with simply stating something that is missing from the specification. This primarily is brainstorming, designing and scoping prior to the start of prototyping work. During this phase the following should be addressed:
Prototyping
After a technical design has been completed, prototyping of a change will begin. This will be testing how effectively a design would work with:
There are many different items to consider during this step and it is where a majority of time might be spent after an initial design is proposed. For each proposal the exact steps of a prototype might be slightly different, but prototype software in general should be linked to the issue for others to experiment with during this stage.
Specification Writing
After a prototype step has been completed for a proposal and the technical changes accepted by the VT Working Group, work can start on the written changes to the specification. This will be done as a PR in this repository and will be merged in once it is ready.
Accepted
Once a final specification change is accepted and merged in via PR, the proposal will be considered accepted and will be part of the V3 final specification.
Closed
At any point during the above process a proposal might be moved to the closed state. Closing simply means that this issue will not be a part of the VT3 efforts. Some ideas might be recycled for later releases or might prompt other actions or efforts to be started.
Timeline
Currently the only hard timeline that we can broadcast is the time period for submission of Technical Designs. This will be closed after July 1, 2018. Other dates in the timeline will be announced as we go through the process.
Questions You Might Have
Who is allowed to participate in this process?
We encourage anyone who has interest in this process to speak up at any stage of the process with their concerns or comments. If you are interested in proposing an idea please check other existing issues before opening a new issue in this repository. If you need any other support with any proposal please
/cc @flippmoke
as necessary. Additionally, you may email me atblake@mapbox.com
.How long will this process take?
The timeline for this will greatly depend on many factors but we hope for a final release within a year at the latest of this process starting.
How do I express my approval or disapproval for an idea?
Please use the thumbs up or thumbs down reactions on GitHub to issues. Short responses of approval of disapproval here could become overwhelming otherwise.
Do we have a code of conduct?
Yes, https://github.com/mapbox/vector-tile-spec/blob/master/CODE_OF_CONDUCT.md. If you have any issue with anyone's actions during this process please email me at
blake@mapbox.com
.Will people outside Mapbox be part of the Working Group?
The Working Group is currently limited to Mapbox employees. If you are outside Mapbox and are looking to have a larger contribution on the specification please email me and we can discuss how you could best work with members of the Working Group and have a bigger role in the process.
Will the specification be moved to a standards body outside Mapbox?
During this process we are not currently planning on moving the specification to be under the review of a standards body. We have always made the specification more open for this migration by licensing it under Creative Commons, but do not have any plans internally at Mapbox to lead such an effort.
How much is likely to change about the specification as part of VT3?
We are not entirely sure at this point. We will learn more as we continue in this process. We are very aware that many people have adopted technology that relies heavily on VTs. We also realize that changes to encoders and decoders can be very difficult, especially when there are multiple versions of specifications to consider. For these reasons alone we are always hesitant to change aspects of the specification as it can possibly cause painful transitions. However, we also want to allow new and exciting features that will make VTs even more useful. We know this is a balance and we are going to carefully consider all impacts of any changes to the specification.
The text was updated successfully, but these errors were encountered: