-
Notifications
You must be signed in to change notification settings - Fork 258
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
Multiple types per source #179
Comments
That makes sense to me. |
IMHO a good idea, but not backwards compatible and given that the format isn't versioned simply changing it would not be nice (as with OSM I assume that we don't really know who is consuming the data, if anybody). |
related discussion: #24 |
after #168 versioning the project becomes automatic |
Well except that my fork will continue to use the old scripts etc. |
How does switching to Node make versioning automatic? |
We publish regular releases to npm and follow semver.. |
Gotcha. We can do that with Python, too, so I was checking if there was something else. |
JOSM uses the notion of |
We also duplicate a lot of polygons - it would be good if we could define one geojson feature, then multiple sources per feature, then multiple types per source. |
An alternative solution to that sub-problem would be to distribute the data (also) in the topojson format, which implicitly gets rid of duplicate outline segments. |
some layers also have mirror url for the same type (for ex a mirror done by a local chapter to use when upstream is down). it would also be usefull to have them in the same layer. this need to allow 2 url for with the same type. |
Right now we have the type property, which is one of
"tms", "wms", "bing", "scanex"
.It would be nice to have each source file include all of the supported types for that source, rather than duplicating sources.
e.g.
The text was updated successfully, but these errors were encountered: