openstreetmap / id Goto Github PK

There are already a few actions, like creating nodes, which are async in the model and will be more async in the future, but their undo states and registered sync. This could lead to race conditions & more problems down the line - undo and do should likely take callbacks.

It should be easy to make the tile endpoint independent of the rest of iD, so we can run iD without tiles as a layer in other systems.

Unless osm.org grows a JSON interface really quickly, we're going to need to serialize XML in this project. There are no native interfaces for this that I can find, and the masses of libraries seem to be really poorly-made.

JXON appears to be one viable option. Going with that.

It looks like it's possible to use plain CSS for a wide number of settings, like roads & buildings. It might be valuable to reduce the complexity in this area.

Not sure how to do this, might have to bug mbostock about this or mod double-click handling to make it possible to double click to a clean zoom.

Not much more than that, soft tabs please! Hard tabs are rarely seen in javascriptland.

Markers that would look fine on a flat map aren't strong enough on satellite data. Example:

We either need backgrounds for these, or just better styled markers.

I'm not clear on what sublayers, as implemented in Map.js and somewhat in other areas, are. Are they levels of data? Of rendering? It looks like we have 10 layers, with 6 groups each = 60 <g> elements nested in the map.

Previously the 'connection' was the central command that could call map.updateUIs via refreshEntity. Possibly entities should know about their UI elements?

There are plenty of places where we can do this if we just go es5. Is it worth it?

Noticing that each entity in the system has a personal reference to the 'connection' object.

Is this because there can be multiple connections and we want to keep track, or is this a convenience for stuff like .refreshEntity?

The subscription system works somewhat well, but it should be possible to use iD.Connection without being a map.

This classic problem. Probably fixable just by using code from d3map

We could probably benefit from some events concept, for stuff like refreshEntity, which previously looped through maps with a more or less 'register callback' system.

Options:

• bean has been good to me
• We can also use jQuery for this
• Or dojo
• Or roll-your-own callbacks system

If the sum of tiled requests to overpass is roughly the same as one request, we should tile our requests so that it's simpler to do differenced-requests for page pans and zooms.

Basically a problem with events not tricking down to the map object - a pan should be detected.

dojo's gfx library doesn't use transforms for stuff like tile translate operations - this is a pretty first-batch optimization to do. we'll either need to do some svg-specific code or see if dojo has a special construct for doing things the nice way.

It might make sense to always show a bit more of the 'skeletons' of objects instead of toggling these on & off. It would make it more obvious to new users how you can change shapes & select points to grab.

If you make an edit, undo it, and then make an edit, the graph state gets messed up. We should have .modify check whether the current state is head and chop off redos if it isn't.

In the process of editing OpenStreetMap, being on site is wonderful. It helps to give feedback with a very short loop about the immediate environment. An issue is that the current editing tools are not very good for matching these two goals at the same time:

1. Editing on Mobile (be phone or tablet) with a fatty finger on a small screen. It needs tools with magnified a bit like precision positioning when fixing text.
2. Offline. This is key. You should not have to be connected to be able to edit the map. Everything could be buffered and exported later when you reach a network. The background tiles should be imported when online then used when needed offline.

If these two features are met it would be very cool. It's indeed hard. I guess sync issues, precisions, number of downloadable tiles in appcache, etc.

There are quite a few attributes, like modified, that are wrapped by setters and getters, like markDirty, markClean, isDirty. Unless there are side-effects to changing these values, I'd rather just deal with public properties of objects than a larger API.

It would be wonderful if instead of around 100 images to download for different markers, we could use a sprite sheet. Not sure if this is doable in SVG - needs investigation.

Could we use something like Maplint as a proofing for changesets made by iD, and try to warn for things that would cause maplint errors? Or is there a better lint to pay attention to?

Fairly easy to support by classing the map container and adding svg styles for .z14 and so on.

It's be simple to add a hash to the URL for map browsing so that it's simple to link to locations.

Unclear what the best approach will be here, but this interface will have to be translatable.

We need to authenticate this guy against OAuth, and probably with some kind of bridge like gatekeeper for now.

CORS is quite certainly the worst web standard lumped in with HTML5. Right now thanks to its unbelievable badness, this is doubling download times by sending an OPTIONS request, waiting for it to complete, and then sending a GET request. Both requests load all data.

Bah humbug.

Unclear, this might be causing problems, I need to investigate whether usage of <path> elements instead of <polyline> is suboptimal.

Right now dragmove calls an expensive drawVector call. It should only redraw affected ways. We know the ways via .entity.parentWays(), but my d3-foo is not enough to reverse-join them...

Besides the regular dragging markers, we should also have the mid-line markers that JOSM has from the 'improve way accuracy' plugin in core.

(this seems like the kind of idea that already exists somewhere)

Could there be a JSON/YAML/plaintext/whatever dictionary of common keys, 'documentation' (basically one-sentence summaries of wiki pages), and 'suggested icons' or such? This could be shared between editors and used for tagging interfaces.

There probably should be a UI for undos, and some nice way of presenting the undo list (like how you can hold down the back button of a browser to get recent history, and graying out the buttons when appropriate).

This is useful for houses, etc. Specifically, this means clicking on the stroke/casing for roads, or the fill for houses, dragging, and moving all nodes.

Hashes don't just need to show the map location, they should also support editing modes and item selection.

We have enough to do this - a good list of annotations - but need to work on the UI in this area in general.

If we choose to go SVG-only, there are a few benefits:

• Consistent mouse interaction in terms of cursor: pointer;
• Using classes for road types rather than styling each road individually

Though, there are definitely drawbacks. Something to keep in mind.

We should use polymaps, modestmaps, etc to do tiling instead of having a self-rolled version; this would give stuff like templated tile urls, touch handlers, etc., for free, and less code to maintain.

What I've been comping out with jQuery for feature editing is not optimal, we'll need a better pattern for handling, validating, and storing user input.

Options (non-exhaustive):

• Backbone or a knockoff
• Following an MVC pattern without a framework
• Using dojo functionality
• Continuing to just hack it

Right now this is an issue with dragging and double clicking. Should be simple to do, but I need to understand dojo's graphics layer better to make sure it can be done with different renderers than SVG as well.

We need an approach for how to handle actions & operations which is pretty robust.

Current approach:

• One action at a time, you can .enter and .exit actions
• Actions bind and unbind their own events and add and remove their own elements
• Actions have access to the map object and graph object

And

• Actions lead to operations, which actually modify the dataset
• Operations lead to versions in the graph.

Need to iterate on the map sizing logic so that we can have fullscreen editors rather than fixed height.

In the within for both Way and Node, the value of this.deleted affects the value of whether one thing is inside of another. This seems like overlapping concerns; shouldn't the caller be responsible for checking whether something is deleted?

This should probably use marker-mid (mdc, example).

So, how do we resolve the question of loading new data into the graph versus having a consistent undo system? Does loaded data have a 'backdoor' where it exists in all graph versions? Does undo possibly wipe data that's downloaded from the map?

It'd definitely be possible to use a simple object-literal in place of jshashtable - I can definitely run this work out if there's no other-reason for using it that I'm not aware of.

@jfirebaugh brought up this idea - essentially (in my n00b terms), this would mean having version tags for each entity, and chains of versions that can reuse entities. This would essentially be our undo strategy, allowing us to go back versions by just traversing the chain.

Since we don't support all browsers, we should have a good way to handle this case. Basically a modal.

There should be a simple way to resize the map, and we should tie this into the window resize event to handle 100%/100% maps.

In order for this to be embeddable, it shouldn't be dependent on owning the page. Likely this means another container element that's relatively positioned so that the absolute positions inside of it are constrained.