scapegoat's People
scapegoat's Issues
Open issue for legend for sources/world/OpenStreetMap-GPS.geojson html in iD - hardcode it in iD?
The GPS traces layer's attribution uses a hack to display a legend:
"html": "<span style='display: inline-block; padding: 0 8px; background-color: rgba(0,0,0,0.5);'><span style='color: #eee;'>GPS Direction:</span> <span style='font-size: 15px; padding-left: 2px; font-weight: bold;'> <span style='color: #0ee;'>←</span> <span style='color: #96f;'>↓</span> <span style='color: #6e0;'>↑</span> <span style='color: #f63;'>→</span> </span></span> \u00a9 <a href='https://www.openstreetmap.org/copyright'>OpenStreetMap contributors</a>."
It's the only layer that uses the 'html' attribution. JOSM doesn't have html attributions:
https://josm.openstreetmap.de/wiki/Maps/Worldwide#OpenStreetMapGPSTraces
We should instead ask iD to hardcode this if the layer id is "osm-gps" or the url contains "gps-tile.openstreetmap.org" or something like that.
Another hack could be to use an icon? It might get shrunk into unreadability.
Sanitize Layer ID
The layer ID is currently used to generate the on-disk path for the icon. This could open a security problem, so those strings should be normalized.
Rewrite check.py to check quality of josm imagery
ELI's check.py checks for missing attributes - missing license, etc.
https://github.com/osmlab/editor-layer-index/blob/gh-pages/scripts/check.py
These checks should be done on the JOSM stuff, and be shown on some kind of monitoring/QA page, a bit like https://josm.openstreetmap.de/wiki/ImageryCompare
GeoJSON output should follow RFC7946 winding order
Probably not something we can fix here, but only in thomersch/grandine#3
Generate 'web' geojson files for iD
iD does some filtering and enriching of tile layers that we should reproduce as much as possible
- Only include wms layers that support the projections that iD can use, with only one projection - already done for MVT
- Layers of type wms_endpoint or wmts stripped out
- Remove a few layers, mostly layers that will be of category 'osm' - see
discard
in iD - Remove layers that are more than 20 years old - see
too old
- Add Maxar layers - see
keep
- Rename attribution attributes: terms_url = attribution.url; terms_text = attribution.text
Round positions to 5 decimals
ELI simplifies all features to 5 decimals:
for file in sys.argv[1:]:
with io.open(file, 'r') as f:
# simplify all floats to 5 decimal points
source_features.append(json.load(f, parse_float=lambda x: round(float(x), 5)))
4 might actually be enough; I was just being conservative when I wrote that.
Properly pre-filter wms projections for MVT
iD supports these projections:
const supportedWMSProjections = {
'EPSG:4326': true,
'EPSG:3857': true,
'EPSG:900913': true,
'EPSG:3587': true,
'EPSG:54004': true,
'EPSG:41001': true,
'EPSG:102113': true,
'EPSG:102100': true,
'EPSG:3785': true
};
These are basically all Web Mercator + 4326
iD also needs to know which ones the wms server supports to create its requests in 3857 or 4326 - our current replacement won't work.
We should:
- If Web Mercator is supported in any way, advertise the layer in MVT with only one of the supported Web Mercator projections
- If Web Mercator isn't supported but 4326 is, advertise 4326 in MVT
- If neither is, don't advertise the layer in MVT at all - it's useless to iD.
Unembed images from josm
The JOSM xml contains a lot of base64-encoded icons. Every single tile we generate will contain, for example, the maxar and mapbox icons in base64.
Using https://github.com/osmlab/editor-layer-index/blob/gh-pages/scripts/unembed-icons.py , unembed them and host them on https://imagery.openstreetmap.lu/icons/
Serve pre-compressed files
Using https://nginx.org/en/docs/http/ngx_http_gzip_static_module.html and maybe https://github.com/google/ngx_brotli , pre-compress tiles on server.
Remove trailing 0s from positions
One tile I'm looking at contains:
"geometry": {
"type": "Polygon",
"coordinates": [
[
[
5.62500000,
48.92249926
],
[
8.43750000,
48.92249926
],
[
8.43750000,
50.73645514
],
[
5.62500000,
50.73645514
],
[
5.62500000,
48.92249926
]
]
]
}
We should have 5.625
instead of 5.62500000
.
Translations
We know from the Accept-Language headers what the human in front of the screen expects, and can pre-generate some languages, or generate the tiles dynamically for more complex requests (like mine, en-GB,en;q=0.9,fr;q=0.8,de;q=0.7,lb;q=0.6).
We can send a Vary: Accept-Language header to prevent the wrong language from getting cached.
We can pre-embed all available translations in a tile, creating attributes like name:de-CH
. This might produce big tiles, and would have to be understood by clients.
We can generate tiles per language, e.g. 7/42/42-en-GB.geojson. This means that a client would have to download as many duplicate tiles as the human understands.
We can generate translation tiles that would contain only the translated strings, e.g. 7/42/42-en-GB.json. A client would download the 'normal' scapegoat tile and the translation tile for all wanted languages.
We can use the translations from JOSM, from iD, or both.
Separate worldwide and local tiles?
See also #4
Worldwide tiles won't change. Having the clients download one worldwide and one local tile will make further local downloads lighter.
Trigger build every time josm wiki is updated
Have https://josm.openstreetmap.de/jenkins/job/JOSM-Imagery-Integration/ trigger a Scapegoat build whenever the wiki is updated.
Ask sysadmins for imagery.openstreetmap.org vm/dns
Scapegoat currently runs on openstreetmap.lu and one of Thomas's VMs.
We should move to OSM infrastructure when we're ready.
If we only have the default tiles, redirect to default.geojson which can be cached?
Many places aren't covered by any local layers: see the map at https://osmlab.github.io/editor-layer-index/
For example, 17/16 and 18/16 both cover Congo-RDC, and contain the same stuff.
Redirecting to a worldwide.(geojson|mvt) would potentially save three tile downloads. Premature optimisation? See also #5.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.