Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Web maps
Semelhante a Web maps (20)
Último
Último (20)
Web maps
- 2. Background • Maps as fundamental as <video>? • Growth in mobile → more maps? • Apple entering map space
- 3. What’s the problem? • Current systems are closed • Limited facility for: • Offline access • Ad-hoc sharing • Mash-up data • Web should be: • “de-centralized, simple, cooperative” • “autonomous, distributed, cooperative” • Need for open approach • KML just annotation within maps (POI) • GML is XML Schema based, non-trivial
- 5. What’s the problem? • Current systems are closed • Limited facility for: • Offline access • Ad-hoc sharing • Mash-up data • Web should be: • “de-centralized, simple, cooperative” • “autonomous, distributed, cooperative” • Need for open approach • KML just annotation within maps (POI) • GML is XML Schema based, non-trivial
- 7. What is needed for maps in SVG? • Tiling and layering • Non-scaling stroke • Shared paths • Fixed-size objects • Non-linear transformations • UI features • API features
- 8. Tiling and layering • Hyperlinks Source: http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/#Tiling
- 10. Container file <svg xmlns="http://www.w3.org/2000/svg" viewBox="20 110 120 85"> <globalCoordinateSystem srsName="http://purl.org/crs/84" transform="matrix(15.3631,0.0,0.0,-18.6994,-1889.2916,849.9202)"/> <animation x="0" y="0" width="100" height="70" xlink:href="0_0.svg"/> <animation x="100" y="0" width="100" height="70" xlink:href="1_0.svg"/> <animation x="200" y="0" width="100" height="70" xlink:href="2_0.svg"/> <animation x="0" y="70" width="100" height="70" xlink:href="0_1.svg"/> <animation x="100" y="70" width="100" height="70" xlink:href="1_1.svg"/> <animation x="200" y="70" width="100" height="70" xlink:href="2_1.svg"/> <animation x="0" y="140" width="100" height="70" xlink:href="0_2.svg"/> <animation x="100" y="140" width="100" height="70" xlink:href="1_2.svg"/> <animation x="200" y="140" width="100" height="70" xlink:href="2_2.svg"/> </svg>
- 11. <globalCoordinateSystem> <globalCoordinateSystem srsName="http://purl.org/crs/84" transform="matrix(15.3631,0.0,0.0,-18.6994,-1889.2916,849.9202)"/>
- 13. Min & max zoom <svg> <circle cy="100" cy="100" visibleMinZoom="100" visibleMaxZoom="200"/> </svg>
- 14. Applicability beyond maps • Medical imagery? • Large images in general (c.f. SVG 1.2F's multires proposal) • Building blueprints? • Games?
- 15. What is needed for maps in SVG? • Tiling and layering • Non-scaling stroke ✓ • Shared paths – SVG 2? • Fixed-size objects – transform-ref? SVG 2? • Non-linear transformations × • UI features • API features
- 16. UI features • Built-in map controls × • Programming-less geolocation × • SVG views with geographic coords ? • Media frag? xywh=degree:lng,lat,w,h ?
- 17. API features • API for smooth transition action of zooming, panning, rotating • Transformation functions between global/geospatial coordinate systems and user/viewport coordinate systems • DOM access API for cascading SVG documents • i.e. SVGTileElement.contentDocument/contentWindow
- 18. Resources • Spec: http://ww.w3.org/Submission/2011/SUBM-SVGTL- 20110607/ • Offline Web Applications for Disaster Relief - http://www.w3.org/2011/web-apps-ws/papers/KDDI.html • Presentations by Takagi-san: • https://www.w3.org/2011/Talks/kddi-201111.pdf • http://www.slideshare.net/totipalmate/proposal-of-svg-map- 8157601
- 19. Mozilla position • Map UIs are very complex • E.g. positioning of labels, integration with WebGL etc. • Hard to imagine a subset that is implementable in all browsers and still competitive with existing map services • Better to agree on standard markup and create at least one open source Web app to display it. • i.e. client-side but not browser-native • Tiling is generally useful beyond maps • Suggest <iframe> for SVG • Combined with load-on-demand facility and zoom-level control
Notas do Editor
- Bear in mind that mapping is also quite big in Japan. A lot of government agencies make detailed map data freely available and there has been a lot of interest in exchange formats.
- You can already realise mapping applications in script, the Web platform supports it, so what’s the problem?The main problem is that current systems are closed.You’re at the mercy of the mapping service for offline access.It’s impossible to do ad-hoc sharing of map data unless the service provides what you need.And you can’t mash up data from different sources freely except within the bounds of what the provider allows (e.g. KML limits you to POI). e.g. Base map from MapFanWeb, route from Navitime, shop search from Yahoo Maps, POI from Google MapsBasically, the user is not in control
- My experienceITU Telecommunication Standardization Sector (ITU-T), 25 Oct 2011, focus on standards-based disaster relief solutions:"(5) to consider scalable vector graphics (SVG) as a key technology for graphical maps on mobile devices"http://www.itu.int/en/ITU-T/tsbdir/cto/Documents/111025/Communique-final.pdf
- So that’s just one down side of relying on closed technology for maps.You’re really dependent on the mapping service, the user has no control, no flexibility.Takagi-san says the Web should be…- Anyone use systems without depending on anyone- Anyone easily publish diverse contents- Anyone easily mash-up any contents
- * The key thing is that tiles are connected via "hyperlinks" - Webby* Links go from low-res containers to high-res containers* Containers contain a series of links to tiles with coord info
- Of course, containers can be cascaded
- * Links currently by <animation> should become <tile>- Layer file gives x/y/width/height for viewport only (and, presumably, so UA knows which need to be loaded/pre-fetched)- Actual transformation between coordinate spaces is achieved through the <gCS>
- * Specifies transformation from local coords to global coordsData from tiles transformed to global coords, then from global coords to tile spaceBoth the container files and tiles have this on themWhy not just specify in global coords to begin with? - precision - ability to look at the file independently- This information is somewhat redundant with the info in the layer file but supports mashup? i.e. you don't need the containing layer - the coords in the layer is mostly just for establishing the viewport and tell what to loadconcern about the 'matrix' notation being confusingsrsName, Tab suggests ("this-is-a-map")
- same facility, but overlay the data (how to know which data is to be overlayed and which is to be replaced?)
- do with media queries?
- Shared paths -- this is when you have shapes which share an edge. For example, boundaries of countries, esp. when the boundary is dashed. A requirement for SVG2 (http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Shared_paths) but no commitment, at riskFixed-size objects -- e.g. map markers, UI controls i.e. SVG 1.2 Tiny's transform-ref SVG 2 has a requirement for this (http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Constrained_Transformations) but no commitment, at risk Concern about whether this addresses needs, e.g. rotation without scalingNon-linear transformations Not in SVG 2.
- Built-in UI controls for mapping (e.g. controls on <video>)--rejected from SVG 2Programming-less geolocation--rejected from SVG 2 i.e. say "center on current location" w/o using scriptSVG views with geographic coords -- e.g. map.svg#svgView(global(lng,lat,w,h))w and h are in degrees -- like another media fragment identifier (basically xywh=degree:lng,lat,w,h) -- would also be useful to just have x,y (e.g. center the map on my restaurant) -- resolved to add to svgView syntax if tiling and layering supported
- API for smooth transition action of zooing,panning,rotating -- e.g. ability to suspend redraw whilst panning / zooming ? turn off fine detail while panning?Transformation functions between global/geospatial coordinate systems and user/viewport coordinate systems -- accepted for SVG 2 but not listed in requirementsDOM access API for cascading SVG documents -- i.e. <tile> elements need .contentDocument/contentWindow