├── CNAME
├── pwp
├── slide1s.png
├── slide2s.png
├── slide3s.png
├── slide4s.png
└── index.md
├── dashcamref
├── georef.png
└── index.md
├── web_rollback
└── index.md
├── minute
└── index.md
├── cheat_sheet
└── index.md
├── _layouts
└── default.html
├── extracto
└── index.md
├── route_plugin
└── index.md
├── geotiff
└── index.md
├── overmap
└── index.md
├── style.css
├── watchcat
└── index.md
├── feedback
└── index.md
├── legend
└── index.md
├── index.html
├── imcentral
└── index.md
└── pt_editor
└── index.md
/CNAME:
--------------------------------------------------------------------------------
1 | ideas.osmz.ru
--------------------------------------------------------------------------------
/pwp/slide1s.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Zverik/ideas/gh-pages/pwp/slide1s.png
--------------------------------------------------------------------------------
/pwp/slide2s.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Zverik/ideas/gh-pages/pwp/slide2s.png
--------------------------------------------------------------------------------
/pwp/slide3s.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Zverik/ideas/gh-pages/pwp/slide3s.png
--------------------------------------------------------------------------------
/pwp/slide4s.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Zverik/ideas/gh-pages/pwp/slide4s.png
--------------------------------------------------------------------------------
/dashcamref/georef.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Zverik/ideas/gh-pages/dashcamref/georef.png
--------------------------------------------------------------------------------
/web_rollback/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: Changeset Rollback Web-Interface
4 | status: idea
5 | ---
6 |
7 | Really, what's with all the plugins and perl scripts?
8 |
9 | *todo*
10 |
--------------------------------------------------------------------------------
/minute/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: A minute of OpenStreetMap
4 | status: idea
5 | ---
6 |
7 | A daily youtube video that showcases what's happened in OpenStreetMap yesterday, or before that.
8 | Short intro, background music, English announcer, subtitles in several languages. A minute allows for
9 | several brief news (smb blogged smth, new version of smth released, etc) or a dive into visual news:
10 | for example, new osm.org style release can be illustrated for each point.
11 |
12 | Such regular feature would require around an hour of time, probably for several people (e.g. announcer,
13 | newsperson, writer, animator). Not sure if this can be made 7 times a week, but 5 -- why not?
14 |
--------------------------------------------------------------------------------
/cheat_sheet/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: Tags Cheat Sheet
4 | status: idea
5 | ---
6 |
7 | In the first year of learning OpenStreetMap users are keeping *Map Features* and other similar
8 | pages open at all times. Searching for appropriate tags is not easy, and if a user does not have
9 | a reliable internet connection (e.g. in Africa), they might invent their own tags, instead of
10 | waiting for a 4-megabyte page to load.
11 |
12 | The solution is simple: print it out! Actually, no, disregard that. Let's make a number of
13 | A5-sized laminated cheat sheets: one (probably two-sided) for most popular tags, that would
14 | be of no use to experienced mappers, and couple of specific ones: for example, for armchair mapping
15 | or downtown map features.
16 |
--------------------------------------------------------------------------------
/_layouts/default.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 | {{ page.title }}
5 |
6 |
7 |
8 |
9 |
10 | {% unless page.root %}
16 |
17 |
18 |
19 |
--------------------------------------------------------------------------------
/extracto/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: Automated extracts with GUI
4 | status: idea
5 | ---
6 |
7 | A set of scripts to deploy on a cloud servlet, for generation of regular OpenStreetMap extracts,
8 | with a modern web interface for downloading and administration.
9 |
10 | ## Why
11 |
12 | I know, there are a lot of similar tools, and some companies provide daily extracts, and there
13 | are even services for generating extracts on request. Sadly, these are unreliable, shape files
14 | often lack required layers, and bounding polygons sometimes cut out just the part you need.
15 | And nobody publishes their sources! So this is an attempt to create a simple extraction server,
16 | easy installable on a droplet (from 5$ a month), and/or connected to Amazon S3 (3 cent per GB).
17 |
18 | Note: maybe employ Amazon EC2 service, see Michal's Extractotron.
19 |
20 | ## How it works
21 |
22 | ## Configuration
23 |
24 | ## See Also
25 |
26 | * https://github.com/migurski/Extractotron
27 | * https://github.com/mapzen/metroextractor-cities
28 | * https://github.com/mapzen/chef-metroextractor
29 | * http://gis-lab.info/qa/osmshp.html
30 | * http://beryllium.gis-lab.info/project/osmshp/
31 | * http://gis-lab.info/projects/osm_dump/
32 | * http://download.geofabrik.de/
33 | * http://extract.bbbike.org/
34 |
--------------------------------------------------------------------------------
/route_plugin/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: JOSM Route Editing Plugin
4 | status: idea
5 | ---
6 |
7 | The current relation editing is too generic, and there should be a plugin specifically for editing public transport relations.
8 | The complexness of the schema is the main reason why there are so few of those relations, and they are easy to break.
9 | It should be easy to edit and easy to verify connectivity and stops, including their order.
10 |
11 | ## Panel
12 |
13 | The main UI is the route editing panel. When an object is selected, a list of routes going through it is displayed there.
14 | Click on a route to start editing it. On that moment it is higlighted in its entirety, some stats and validation results
15 | are displayed in the panel. There are buttons to add and remove member object (like in *Relation Toolbox* plugin). But
16 | also there are route-specific buttons like "extend to this way" (find a path and include it) and "find stops" (adds all
17 | stops and platforms along the route).
18 |
19 | ## Master Routes
20 |
21 | Most PT routes are bidirectional: there are two separate relations for each direction. It should be easy, as in clicking
22 | a button, to switch between directions, add missing direction (with respect to one-directional highways; this should also
23 | be checked by a validator), create route_master relations and manage tags in general.
24 |
25 |
--------------------------------------------------------------------------------
/geotiff/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: GeoTIFF Processor
4 | status: idea
5 | ---
6 |
7 | A two-part system for processing GeoTIFF images and making tile layers out of them.
8 |
9 | ## Processor
10 |
11 | A web page with an upload and URL fields. The latter one is for Landsat images. It automatically
12 | downloads an image, for landsat it does pansharpening and color correction. After initial processing
13 | it offers two or more options: with no color correction, basic constrast stretching etc.
14 | When an option is selected, jpeg tiles are created, and all temporary files are removed.
15 | The tile layer is accessible by a unique URL (maybe entered when selecting a color option).
16 |
17 | ## Tile merger
18 |
19 | So we have a lot of separate tile layers, but need to create a single one. Firstly, there is a proxy
20 | GCI script that returns all merged tiles.
21 |
22 | ### Simple solution
23 |
24 | After creating tiles empty ones should be detected and deleted. In a manager script just enable
25 | and disable layers. Proxy script returns the first existing tile for given numbers.
26 |
27 | ### Layer editor
28 |
29 | An interactive map that shows layers in a current view, allowing to enable/disable them. Also
30 | it can selectively remove or restore tiles of a top layer. This allows for removing cloudy parts
31 | and more fine-grained control of layer edges. E.g. we could add a layer just for a single road.
32 |
--------------------------------------------------------------------------------
/overmap/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: Video Map Overlay
4 | status: idea
5 | ---
6 |
7 | So let's assume we have a dashcam video [like this](https://www.youtube.com/watch?v=HgiZ72tsyoE).
8 | It would be nice to have a moving mini-map in a corner, that would show
9 | map (or a satellite view) of a current location, maybe along with a speed.
10 |
11 | Possible overlay configuration options:
12 |
13 | * tile source (regular osm, transparent, satellite).
14 | * zoom: fixed or based on speed.
15 | * width, height, margin.
16 | * round or square.
17 | * opacity.
18 | * rotating or north-top.
19 | * icon for the camera.
20 | * style for the optional speed: font, size, corner of the mini-map.
21 |
22 | The result would possibly be a series of frames, which can be then overlaid onto
23 | the original video with ffmpeg.
24 |
25 | This all could be done in a script, no point in creating a GUI. Or maybe a simple GUI
26 | for configuring an overlay, but without a video.
27 |
28 | Georeferencing frame is a harder task. A single GPX trace should be prepared.
29 | But timestamps mean nothing. Maybe use a player that shows frame numbers,
30 | and correlate some of these with points in a trace. If the trace has no timestamps,
31 | this also would be used to reference it. The result might be just a plain text file.
32 |
33 | Said correlation file can be then used for [dashcamref](../dashcamref/).
34 |
35 | Also we can add waypoints. Either static (from waypoints in GPX I guess), or
36 | moving (separate GPX).
--------------------------------------------------------------------------------
/style.css:
--------------------------------------------------------------------------------
1 | body,html {
2 | margin: 0;
3 | padding: 0;
4 | color: #222;
5 | background-color: white;
6 | font-size: 12pt;
7 | font-family: "Open Sans", sans-serif;
8 | }
9 |
10 | body {
11 | max-width: 700px;
12 | margin: 50px auto;
13 | }
14 |
15 | h1 {
16 | font-weight: 600;
17 | font-size: 20pt;
18 | text-align: center;
19 | color: #111;
20 | margin: 0 0;
21 | }
22 |
23 | h2 {
24 | font-family: "Open Sans Condensed", "Open Sans", sans-serif;
25 | font-size: 16pt;
26 | font-weight: 700;
27 | }
28 |
29 | #content {
30 | margin: 2em 0;
31 | }
32 |
33 | #content a {
34 | color: #222;
35 | }
36 |
37 | .idea {
38 | margin: 1em 0;
39 | }
40 |
41 | .idea h2 {
42 | margin-top: 0;
43 | }
44 |
45 | .idea p {
46 | margin-bottom: 0;
47 | }
48 |
49 | .idea > a {
50 | display: block;
51 | color: #222;
52 | text-decoration: none;
53 | padding: 6px;
54 | }
55 |
56 | .idea > a:hover {
57 | background-color: #eee;
58 | }
59 |
60 | .idea > a > h2 {
61 | text-decoration: underline;
62 | }
63 |
64 | #status span {
65 | padding: 0 4px;
66 | color: black;
67 | }
68 |
69 | .status-idea { background-color: #ddd; }
70 | .status-abandoned { background-color: #fee; }
71 | .status-taken { background-color: #ffa; }
72 | .status-finishing { background-color: #aaf; }
73 | .status-done { background-color: #afa; }
74 |
75 | #return, #footer, #status {
76 | font-size: 10pt;
77 | text-align: center;
78 | }
79 |
80 | #return {
81 | text-align: left;
82 | position: absolute;
83 | top: 20px;
84 | }
85 |
86 | #footer a, #return a {
87 | text-decoration: none;
88 | color: #222;
89 | }
90 |
91 | #footer a:hover, #return a:hover {
92 | text-decoration: underline;
93 | }
--------------------------------------------------------------------------------
/watchcat/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: Watchcat JOSM Plugin
4 | status: idea
5 | ---
6 |
7 | This is a simple watcher plugin for JOSM. It regularly downloads diff files (minutely/hourly/daily, depending
8 | on how long ago JOSM was last used) and monitors changes for given objects. It would be highly useful for
9 | posessive mappers who don't like their objects touched, but also for mappers concerned with validity of
10 | public transport or bicycle routes, or for watching a state of disputable features.
11 |
12 | ## Presentation
13 |
14 | _(picture todo)_
15 |
16 | ## How it works
17 |
18 | Watchcat is a plugin which has it own panel, but that is not required to be open to operate. It maintains
19 | a list of watched objects, just id and type for each. For displaying purposes it can also store textual
20 | description generated by JOSM. To watch an object, select it (or group of objects) and click a button.
21 | You are obviously not notified of edits made by yourself. The plugin can also be configured to add all
22 | modified objects or just those with chosen tags (e.g. all relations, or just routes).
23 |
24 | To edit a list of watched objects it would download all of them in a new data layer,
25 | so instead of searching for it in a list you can select it and press a button.
26 |
27 | When JOSM starts, the plugin download all daily/hourly/minutely diffs and looks for objects in the list.
28 | After that it downloads minutely or hourly diffs (it should be configurable). Notifications are unobtrusive:
29 | changes are just shown in the panel, sorted by time, with an option to clear that list or download objects
30 | or open a relevant changeset in a browser. If the panel is not visible, it can employ an unobtrusive
31 | notification mechanism that was introduced lately.
32 |
--------------------------------------------------------------------------------
/feedback/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: Changeset Feedback
4 | status: idea
5 | ---
6 |
7 |
Right now there is little feedback in OpenStreetMap. Basically, if you edit something, your changes almost surely would go
8 | unnoticed, and if not, the first feedback you will get may come from DWG. We can fix that by making a small improvement to osm.org.
9 |
10 |
Let's assume someone has tagged all McDonald's amenities as restaurants. What do you do then? First thing would be asking a user
11 | why did he do it. Right now the only option you have is to use private messages: "Hello, good day to you sir, I'm sorry for bothering you..."
12 | etc etc. It is too hard, especially for introverts who I think are the majority in OSM. But there are no other options.
13 |
14 |
There was an attempt to add ratings to OpenStreetMap: [+] and [-] buttons which affect both changeset and user ratings. With
15 | this feedback tool user can easily know whether their edits are good, but actually it doesn't show any sense. If someone uploaded
16 | a changeset, they surely consider it good, so positive votes bear no meaning: they already know that it's good. And in an opposite
17 | case, negative votes are often taken personally: "your edits are bad and you should feed bad". Total ratings value cannot be
18 | taken seriously, because every vote means something, so adding those numbers is like adding apples and shades of blue.
32 |
33 | todo
34 |
--------------------------------------------------------------------------------
/legend/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: Legend Generator
4 | status: idea
5 | ---
6 |
7 | Writing a route legend (that is, route turn-by-turn description) is hard and cumbersome. You have
8 | to open google street view, a route, a map and a text editor, and using all four construct a
9 | 20 to 60 direction messages, that have to be short, unambigous and obvious. Veloroad members
10 | are now using plotaroute.com for this task, but we can build simplier and more configurable
11 | website.
12 |
13 | ## Planning a route
14 |
15 | This should be a special Leaflet-based map, on which points are thrown, and it draws a route
16 | using GraphHopper or other cycle-routing service. Each segment between points has a type:
17 | hand-drawn, routed for bicycles, routed for cars (e.g. when we don't want to use cycleway along
18 | the street). Segments are calculated when any of its end markers are moved (or deleted), but
19 | calculated traces are stored as linestrings, so we don't bother routing servers much.
20 | Hand-drawn segments are shown as straight lines from start to finish, which a user can
21 | split using middle-segment markers (as usual). Segment type can, of course, be changed at any
22 | time: e.g. one can get a route from A to B, then switch it to hand-drawn mode and fix some
23 | turns.
24 |
25 | ## Turning points
26 |
27 | A route description consists of many instructions at intersections and non-obvious turns of a route.
28 | Locations of these instructions are placed on a route independently of route points.
29 | They can be dragged along the route. When a new segment is created, at can automatically add
30 | to instruction points array: e.g. when a route engine provides turn instructions, or when
31 | hand-drawn route has turns of more than 80°. Each instruction can be freely edited.
32 |
33 | For each instruction point the distance from previous one and the start of the route
34 | is calculated. Also, the time of opening and closing (useful for checkpoints) is
35 | calculated, based on a number of distance/speed coefficients, like in current
36 | marathon tables.
37 |
38 | ## Database
39 |
40 | All routes are stored in a server-side database. A route data consists of:
41 |
42 | 1. Route points.
43 | 2. Route segments between these points as linestrings.
44 | 3. Type of route segments.
45 | 4. Instruction points: location (lat/lon), text and type (CP, cafe).
46 | 5. Whole route data: title, length, description etc.
47 |
48 | The system doesn't need an authorization system: as in MapBBCode Share, anyone who
49 | has a special link can edit the route. Maybe there should be an administrator's account
50 | with editing rights for all routes.
51 |
52 | ## Printing
53 |
54 | Aside from obvious exporting of a route to gpx/kml/plt formats and a web view,
55 | this tool should automatically generate a map (using nik4cgi service)
56 | and a legend in html, or better, in an LibreOffice Calc table.
57 |
--------------------------------------------------------------------------------
/dashcamref/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: Dashcam Georeferencer
4 | status: idea
5 | ---
6 |
7 | A stand-alone application for extracting frames from a dashcam video and georeferencing them
8 | based on a GPX trace. Takes into account there could be several trace parts and a lot of videos
9 | (maybe recorded with 10 minute intervals).
10 |
11 | ## Loading
12 |
13 | First, a user should open all traces. Since we consider GPS time ultimately accurate, no adjustment
14 | needed there, just glue all these traces together (with holes, but no overlaps). After loading,
15 | traces lose their granularity and become continous lines, so we can align frames with subsecond
16 | precision.
17 |
18 | On the contrary, video timestamps are mostly inaccurate (that's why we need this tool). We can be
19 | relatively sure only of relative time intervals. We load videos one by one: maybe batch mode can
20 | be implemented later, if needed. New videos are appended at the end of last one georeferenced.
21 |
22 | Also this tool in theory can be used to fix photo georeferencing, so it might be possible
23 | to load photos. But this is a bit harder (we need to read EXIF, and save it so image data
24 | is preserved), and not a priority.
25 |
26 | ## Choosing images
27 |
28 | It's unclear whether images for saving should be chosen when opening a single video, or separately,
29 | after loading all of them. Probably the latter. Basically the only setting is frame frequency:
30 |
31 | * time interval between frames (e.g. 2 seconds)
32 | * minimum distance in meters (e.g. 10 meters)
33 | * maximum distance in meters (e.g. 50 meters)
34 | * alternatively, distance in meters between frames (e.g. 20 meters)
35 | * maybe different distances in relation to speed (60 kph in cities, 90kph in rural areas)
36 |
37 | ## Georeferencing
38 |
39 | 
40 |
41 | Blue dot is a video frame, big blue dot is a frame to be saved. Drag big blue dot with a mouse to
42 | choose different adjacent frame to be saved (so you not actually "drag" a dot, but select another).
43 | Double-click a dot to make it saved, or vice-versa.
44 |
45 | Yellow dot is a georeferenced frame. We know its exact location (well, to an extent). Georeferencing
46 | has subsecond precision, so when you drag a dot with a Ctrl, you make it yellow (there can be more
47 | that one yellow dot: linear scale) and can place wherever you like. There should be an option to
48 | prevent user from creating more than one or two referencing frames (so they have options to cancel
49 | or replace reference points).
50 |
51 | When you hover over a dot, its direction of view is shown. It also should be adjustable, with options:
52 |
53 | * this frame
54 | * from this frame to the end
55 | * from the start to this frame
56 | * all frames
57 |
58 | A frame that is selected (or hovered over, needs responsiveness testing) should be displayed near
59 | the map.
60 |
61 | ## Saving
62 |
63 | It's simple: choose an output format (usually jpeg) and quality, and wait. Coordinates, direction
64 | and timestamps are written in EXIF. If source is photographs, just update EXIF fields, not changing
65 | other data.
66 |
67 | Also allow for saving/restoring "projects": a list of files and frames with associated data. Paths
68 | should be relative.
69 |
--------------------------------------------------------------------------------
/index.html:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: Ilya Zverev's OpenStreetMap Ideas Box
4 | root: true
5 | ---
6 |
7 |
85 |
--------------------------------------------------------------------------------
/imcentral/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: Imagery Central
4 | status: idea
5 | ---
6 |
7 | For some services (like validators) we often need to know if it is possible to quickly map at a certain point.
8 | That is, if there is detailed imagery available: Bing, MapBox or other. Usually this results in another Bing
9 | pinger, but the smarter solution would be to centralize this.
10 |
11 | "Imagery Central" is a proxy between imagery providers and validators. It answers a simple, single question:
12 | "Is there a detailed imagery at these coordinates?" It handles caching internally, and check for imagery
13 | updates. It could provide its own web interface to handle bigger updates and to browse statistics.
14 |
15 | http://imcentral.osmz.ru/query?lat=...&lon=...&provider=...&force=0&format=...
16 |
17 | Here `lat` and `lon` are coordinates, `provider` is a comma-separates list of imagery providers (if missing,
18 | imcentral checks all providers), and `force` flag requests cache update. Formats can be `xml`, `json`, `csv`.
19 | Return codes might be as follows:
20 |
21 | * 0 — no detailed imagery at given point
22 | * 1 — there is detailed imagery
23 | * 2 — no data, ask later
24 | * 9 — system error
25 |
26 | ## Imagery Providers
27 |
28 | Providers are identified by a simple alphanumeric string, like `bing` or `orbview3`. `-` is allowed
29 | for word separation (e.g. `ov3-rus`). The list of providers should be accessible via API call and/or
30 | with a web interface.
31 |
32 | Sources can be of two types, probably extensible with plugins: simple tiled and geometric. Simple
33 | tiled sources, like Bing and MapBox, provide just images. By analyzing them, e.g. by checking file size,
34 | we can determine if there is detailed imagery at given zoom, or a tile is blank. Resutls of such testing
35 | should be cached, not to overload tile providers' servers.
36 |
37 | Geometric sources provide exact bounds to their imagery, so it is possible to test the imagery with a
38 | simple geometric query. For example, OrbView3 sources usually provide Shape files with bounds, which
39 | can be loaded in Imagery Central to test against.
40 |
41 | ## Caching
42 |
43 | Since tile requests happen at zooms 14+, and there are hundreds of millions of tiles there, test results
44 | should be cached. Along with tile coordinates and test results, a hash of a tile image should be stored.
45 | Once a minute a random tile should be tested on each of tile providers, to see if there was an update.
46 | Updates should be treated as major events: a notification should go off, a bunch of tiles neighbouring
47 | the updated tile should be removed from cache, signal tiles at bounds of that cleared area should be
48 | added to non-prioritized update queue, and so on.
49 |
50 | There are two queues: non-prioritized, which searches for updates, and prioritized, populated with
51 | `force=1` parameter. Actually, there would be another one, immediate, for tiles requested synchronously
52 | (when they are not yet cached, and bandwidth limits allow). A great care must be put in limiting
53 | requests to tile providers, to not be banned and to not burden servers much.
54 |
55 | ## Web Interface
56 |
57 | Besides the usuall stuff like API reference and statistics, the web interface can also provide
58 | an interactive map with available coverage for each of the providers. It can be enhanced in a way
59 | of "Bing Analyzer" tools, letting users pan the map and "fill" areas, though again, not in a way
60 | that would overload imagery servers.
61 |
--------------------------------------------------------------------------------
/pwp/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: Proper Walking Papers
4 | status: idea
5 | ---
6 |
7 | *This is a copy of [my rant](http://www.openstreetmap.org/user/Zverik/diary/26107) in OSM diary,
8 | with slides from my presentation at SotM 2013.*
9 |
10 | Walking papers (or field papers) are still produced from tiles. Fieldpapers.org, the "modern" service for generating atlases, is more than two years old and is a slight update to older walking-papers.org, built in 2009. It stiches tiles and produces a PDF file. You have no control over map style, you can't even use your own tiles. "Toner" style, which is the best option, are updated infrequently: you might have to wait a week before traced buildings appear on it. And some of them still won't, since it's hard to grasp how it works and why it hides some features unpredictably. Finally, pages of an atlas will be oriented by cardinal directions, in a grid with 90° angles. Of course, not many towns have such proper road network, so you will have to choose smaller scale, with less effective area for mapping.
11 |
12 | 
13 |
14 | I think I can fix this. It is easy, really: most of building blocks for a proper solution are already invented. First, an interactive map, on which you place rectangles for pages. Arbitrarily, not neccessary in a grid. Maybe draw some lines, which would be "pie segments": instead of using MS Paint for making a pie, use some advanced technology. Maybe integrate it with MapCraft. So, a bunch of rectangles on a map. Not 90°-aligned: rotate them as you like. Align with road network, with streams etc, so areas for filling in take as much space as possible, and scale is biggest you can get. When done, just save your work and close the website. Go trace some buildings and tracks.
15 |
16 | 
17 |
18 | When a morning of a mapping party comes, open the website and press "Create atlas". It will display the progress, but the atlas will be made on a server asynchronously. First, it downloads an area from OSM API. Yes, not from a local postgis database, only fresh data. An added bonus (for local installation) is that you can use cached osm data, or just bring it from another computer, if an internet connection is weak. Then it applies a MapCSS style (which you can customize, even upload some of your own or josm's) and renders each page, rotating data as needed. Then it joins pages into an atlas and provides a download link. Later the atlas can be rebuild, using fresh data, maybe a different style or with more pages.
19 |
20 | 
21 |
22 | I don't believe in scanning pages for using them as a layer in JOSM (Bing/MapBox imagery make for a better reference layer), but georeferencing marks probably can be included. That won't be the greatest feature, because I have some other thoughts. You know the weakest point of the OpenStreetMap mapping in 2014? Updating data. It is quite easy to collect and map new roads, new POIs, new restrictions. But updating it is very, very hard, almost impossible for rich regions. There are no tools. My theoretical walking papers can fix that issue. Since we have full control over data, we can put POIs and relevant tags right on pages. We have a second side: for example, on the map there would be dots with coordinates (A4, D9), and on the reverse side — tags for each dot. And the same for ways and maybe relations (didn't think it all through, obviously). So you can have not only a base map for collecting new data, but also a check list for updating the already rich map.
23 |
24 | This solution will make mapping easier not only in third-world countries (where internet is sparse and you can't rely on external web services, or spend days installing tile rendering stacks), but in densely mapped cities, where data has not been updated for years, because it already seems well-mapped, why go there again.
25 |
26 | 
27 |
--------------------------------------------------------------------------------
/pt_editor/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: Public Transport Editor
4 | status: idea
5 | ---
6 |
7 | If we need a plugin, the tagging schema is too complex. For routes, we can make a simple web editor.
8 |
9 | ## Viewer
10 |
11 | An interactive map. Download all stops and platform from the Overpass API and display them.
12 | On click, a list of routes via this stop are displayed. When no stop is selected,
13 | a user can choose a route to view. For a route, all tags are displayed, its stops
14 | are highlighted, and a route is drawn either with ways in the relation, or directly
15 | connecting stop to stop from beginning to end. The latter allows for displaying
16 | routes with no or obsolete route data.
17 |
18 | When a route has `route_master` relation, an additional panel is displayed above
19 | tags and stops, with a list of route variants. By clicking on each, a user can quickly
20 | browse through all of these. Route variants do not appear in a full list of routes,
21 | masters are shown instead. But when clicking on a route master, the first variant
22 | is displayed.
23 |
24 | So, we have three panels: list of routes in a viewport, stop/platform data with
25 | all routes passing through it, and a route variant data.
26 |
27 | ## Editor
28 |
29 | A user can enter edit mode by logging in to OSM via OAuth. Then he has some options:
30 |
31 | * Add a stop on the map: select type (stop position on platform) and route type (bus, tram etc.),
32 | then drag a marker: for a stop position, it will be moved to a nearest highway or tram line.
33 | After all that, a user should fill out a form, though if they don't know even a name
34 | for the stop, they can submit just the addition of a stop.
35 |
36 | * Edit a stop: add a name, for example. This is a sample tag editor with the ability
37 | to move a node. For a stop position, care should be taken to not detach a node from
38 | its way, and not to mess node order. Also, a route can be added to the stop: first,
39 | user should select a route master, and then -- its variant. And he gets pulled to...
40 |
41 | * Editing a route variant. There are tags, and a list of stops and platforms (which
42 | are linked together). User can swap stops, duplicate any stop, and add or remove stops
43 | from the route with a simple click on the map. When adding, stops are added according
44 | to their geometric position in relation to other stops.
45 |
46 | * Create and delete a route variant. When creating, the mode is changed to editing,
47 | so a user can immediately click on stops along the way. No reversal function should
48 | be available, since all stops are different. Although stops from other route variants
49 | can be somehow highlighted. Deletion of a route variant with more than three stops
50 | should be forbidden.
51 |
52 | * Create or delete a route master. Should be done from a route variant editor somehow.
53 | Like, when the last route variant is deleted, its master should be also deleted.
54 |
55 | So, there are a lot of editing options, some of which are quite complex. Maybe it
56 | should be done in stages, e.g. first with only editing existing routes and stops.
57 |
58 | ### Stops And Platforms
59 |
60 | Since all platforms should have their related stop positions, and vice versa,
61 | it should be reflected in the user interface. For example, viewers and editors
62 | for both should be combined, with options to add corresponding stop or platform.
63 | There should be additional tests for broken relations or differently-named
64 | nodes, e.g. with a distance limit.
65 |
66 | I guess it's safe to assume stop positions at all times should be named the same
67 | as their platforms.
68 |
69 | ## Ways
70 |
71 | Editing ways in a web interface is hard, and we are stepping on a territory of
72 | a complex OSM editor. Editing a route can be done in either of two ways:
73 |
74 | * By clicking on road segments. All highways are visually split into segments,
75 | regardless of their ways, and a user clicks on each they want to add to a route.
76 | Oneway-ness and connectiviy are, of course, validated.
77 |
78 | * By building a route with a third-party routing engine. A user clicks on a start
79 | point, end point, and places some intermediary points along the route. After
80 | that, we get a list of way segments for a route.
81 |
82 | These interfaces could be combined: for example, first we use a routing engine
83 | to build a draft version of a route (maybe automatically from stop positions!),
84 | and then for editing we allow user to click on road segments.
85 |
86 | There should be an additional check that all stops are near the route. Though
87 | it is not completely clear what to do if they are not.
88 |
--------------------------------------------------------------------------------