Display nodes that have tags #57
Conversation
Should make it easier to start development.
And as a consequence, declare some variables that were not declared, yet.
Since OSM data, changeset comments and potentially even OSM usernames may contain HTML code, it's better to use the textContent property to insert such values, since innerHTML would result in interpretation of this HTML code which might even result in the execution of JavaScript code [1]. The Underscore.js template is also affected by such issues, which can be mitigated by using <%- instead of <%= for interpolations [2]. [1] https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML#Security_considerations [2] http://underscorejs.org/#template
The 'or' operation is redundant in these cases since both operands are identical, and can thus be removed.
is_a_way is not modified in the true-branch of the condition, so it's still true when returning from it and can thus be removed from the expression.
This is more generic and the wiki [1] also talks about elements when describing ways, nodes and relations. Prefixing 'map' prevents confusion with DOM elements which are also common in such an application. [1] https://wiki.openstreetmap.org/wiki/Elements
… generic As neither change.type, change.old.tags nor change.neu.tags is modified in the loop, the value of tags will always be the same, so this can be moved outside the loop. Instead of using the hard-coded 'a way' text for the fallback tag text, take the actual element type from the change, which is more generic in case the element is something which is not a way.
…ield The type of an element does not change, so this seems a little simpler and should make it easier to support other element types.
Makes the functionality more reusable for other element types.
Done just like for ways, but with a L.CircleMarker instead of a L.PolyLine. Also added a few more tags which should be shown that are often used on nodes, but at least some of them may also be used on ways.
|
@mstock thanks for working on this! I tagged a version of osm-stream with the fix for more than ways as 0.0.14. Can you update the package.json here so it uses it, then we can try it out? |
This version actually provides tag information for nodes, so with this they get displayed.
|
You're welcome :). I just pushed another commit which updates |
|
Yea, that probably will be ok for now. I'm not sure I have access to the npm project 🤔 |
|
This looks great, thanks! |
|
Thats very cool! |
|
Yep, it should be. |
|
Thanks. It's hard to validate from outside; I'm still waiting to see a node popping up :-). |
|
Actually, I don't think it is - the GitHub page uses the 'compiled' |
|
Ah, you're right! Thanks for looking into it. It's been a while since I've made a change on this repo 😄. I'll re-build bundle.js and push it up for now. In the longer term we could switch over to a replacement for GitHub Pages that will build the bundle.js for us. |
|
I pushed up the updated bundle, but I haven't seen a node show up yet. Let me know if you find one. |
|
I took a look at the 'compiled' In order to automate the build with GitHub pages, one could probably use TravisCI - I've never tried this though, and since it requires a personal token, TravisCI will likely get write access to all repositories the creator of the token has access to (so I'd try to create a second GitHub user for this, and only grant this user access to those repositories where this is required - I don't know if this is actually supported though), and it might also be a good idea to start doing development on a different (like |
|
I pushed the updated bundle.js and am seeing nodes on the deployed site. Looks good! This highlights how much is happening in OSM, and that this tool might need to group these changes together so that we spend less time jumping around the world. |
Issue #56 requested that nodes should also be displayed. The suggested changes in this pull request add this functionality by placing a marker for nodes that have been created, modified or deleted if the node has any tags.
Since this requires that tags are also part of the data structure that is provided by
osm-stream, it currently has no visible effect though, since tag parsing for nodes only becomes available if/when osmlab/osm-stream#13 (or something similar) gets merged, which currently has a syntax error that could be fixed by applying a trivial patch like the one in mstock/osm-stream@56bf6bd. Once that pull request is merged, somebody would have to cut a release ofosm-streamand then the corresponding dependency inshow-me-the-waywould need updating.The first five commits in this pull request are mainly smaller code cleanups and fixes - I can extract them to a different branch and create a separate pull request or even drop them if you prefer.
For demonstration purposes, I've deployed a build with the node feature that uses a patched version of
osm-streamon my Github page.