vmarc/knooppuntnet

Route planner and quality assurance for walking and cycling networks in OpenStreetMap.

knooppuntnet

Table of contents

• About
• Screenshots
• How to contribute?
  • Translations
  • OpenStreetMap mapping
  • Reporting issues
• Credits

About

Knooppuntnet is a website for planning routes through walking, cycling and other types of node networks in OpenStreetMap. It provides support for analysis and quality assurance of these networks, and monitoring long distance walking routes.

• knooppuntnet.nl

• wiki documentation

Screenshots

You can plan a walking route by clicking on a start node and destination node (and optionally intermediate nodes that you want to pass through). You can output the planned route in a pdf document and/or a gpx track.

In the analysis section of knooppuntnet, you can get an overview of all nodes and routes in a given node network, and explore issues that knooppuntnet finds. Directs links to editors make it easier to fix problems in the OpenStreetMap database.

You can look at the changes to the OpenStreetMap database that affect the node networks in near realtime.

For long distance walking routes, you can compare GPX traces with the mapping of the route in OpenStreetMap. This allows you to find problems in the OpenStreetMap database and/or the GPX trace.

How to contribute?

Here are a number of ways of how you can contribute to the project:

• validate routes on the ground

• map additional nodes/routes/networks

• report errors

• application translation

• documentation

• application testing

• application code

Translations

The intention is to have knooppuntnet available in four languages: English, Dutch, German and French.

Wiki

The application documentation is in the OpenStreetMap wiki. Feel free to add to this and/or translate to other languages.

Application

Your help in translating the application to a language that is not fully translated yet, or to fix wrong translations, is very welcome.

The base language for the application is English. Support for translation to the other languages is kindly provided free of charge by POEditor. POEditor supports open source. Many thanks!!!

Follow this link to join the knooppuntnet translation project.

From the project start page you can select the language. In the "Translations" tab you can review all translations (select "Show: translated"), or bring up the list with all texts that still need translation (select "Show: Untranslated"). From these lists the translated texts can be entered and/or changed. Click the text to start editing.

All the translations you make here will appear in the knooppuntnet website in the next release.

The above is sufficient to help out with the translations.

A bit more advanced: if you like to review your translation changes without waiting for the next release, you can follow the instructions in the section "Install application locally" below.

In the POEditor page for your language, you can go to the "Export" tab. Select "Show Advanced Options". Select "Export: All" and "Filename: translations.XX.xlf" where XX is the 2 letter code for given language:

Language	Command
Dutch	translations.nl.xlf
German	translations.de.xlf
French	translations.fr.xlf

Klik "Export" and save the file in the "locale" directory in your git clone:

knooppuntnet/frontend/src/locale

To see your translations in action, restart the application in development for given language, for example (from directory knooppuntnet/frontend):

npm run serve:translation:de

Note: changes to the English texts have to be done directly in the application code.

Install application locally

These are the instructions for installing the client application on your local computer (for development purposes).

node.js and npm

We use "npm" to manage the software dependencies and to help in installing and running the client application.

If you do not have a version of node.js installed, please follow the directions for installation on nodejs.org.

git

We use git as our version control system. Although it is also possible to download the code as a zip file, it will be easier to immediately use git, especially if the intention is to contribute to the project afterwards.

Go to git downloads and follow the installation instructions.

Install and run

Get the source code:

git clone https://github.com/vmarc/knooppuntnet.git

Install the software and fetch all dependencies:

cd knooppuntnet/frontend/
npm install

Build and run the client:

ng serve

In a web browser on your computer, open:

http://localhost:4000

The above command will build and start the English version of the application in development mode. Use one of the following commands to start the application in another language:

Language	Command
Dutch	npm run serve:translation:nl
German	npm run serve:translation:de
French	npm run serve:translation:fr

When starting the application in a language other than English, the texts that are not translated yet are shown in English.

OpenStreetMap mapping

You can contribute by adding, updating or reviewing the node and route definitions in OpenStreetMap. Any changes made there will become available in the application soon after upload to OpenStreetMap.

Reporting issues

Issues can be reported in github, or through an OpenStreetMap message to vmarc.

Note: when submitting issues, please feel free to use English, Dutch, French or German.

Application testing

Review these documented planner interaction tests.

Credits

Knooppuntnet is happy to use an IDE from JetBrains who provided an open source license.

Translation support for the application is provided by for free by POEditor (supporter of open source projects). You can join the translation effort at their web-site.

All map data is coming from OpenStreetMap.

Background map tiles are created with OpenMapTiles using OpenStreetMap data extracts provided by Geofabrik.

The client is using Angular, Typescript and OpenLayers.

The server is using the Scala programming language, SpringBoot, MongoDB database, a local OverpassAPI instance, JTS topology suite, JGraphT, ScalaTest and others.

Point of interest icons are by Map Icons Collection.

Other icons are from www.flaticon.com and are licensed by CC 3.0 BY. These icons are made by: Scott de Jonge, Vitaly Gorbachev, Freepik, Plainicon, Google, Smashicons, dmitri13 and Roundicons.

knooppuntnet's Issues

Connections to other network are not taken into account in integrity check

For the integrity check only the non-connection routes are taken into account. This results in an false-positive at nodes near the edge of a network.

Example: https://knooppuntnet.nl/nl/node/42585285
Node 6 is in the network of Geldrop-Mierlo. It should have three routes according to the tag expected_rwn_route_relations. Indeed this node has three routes (2-6, 6-27 and 6-50).

However, route 6-50 is a connecting route to node 50 in the network of Heeze-Leende. Therefore it seems that it is not taken into account for the integrity check. This brings the number of routes to two (2-6 and 6-27) and the integrity check fails, even when it is tagged correctly.

In short, the integrity check should be done in the network of which the node is a member (Geldrop-Mierlo in this case, not Heeze-Leende), but it should take all routes of this network into account, also the routes with role connection.

Natural sorting order for nodes and routes

Node lists (example) and route lists (example) are sorted on node name and route name respectively. The sorting is string based. For example: node "3" follows node "29".

Should use natural sorting order for nodes and routes instead.

Reported by A67-A67 (thanks!).

Bij het sorteren van knooppunten en routes komt 19 voor 2. Dit was ook bij osma.vmarc.be en het levert een reden op om voorloopnullen te taggen die niet bestaan. Hier is al meerdere keren discussie over geweest en de consensus komt neer op taggen wat in het veld te zien is. Dus knooppunt 2 wordt rwn_ref=2 en knooppunt 02 rwn_ref=02. Een natural sorting algoritme kan dit probleem oplossen.

Allow navigation from node and route maps

It would be handy to be able to navigate to nearby nodes and routes by clicking on the nodes and the routes that are shown on the node and route detail pages.

Thanks to Maarten Deen for this suggestion.

Incorrectly ignored relations in rwn Roermond

Some nodes in walking network Roermond fail integrity check because some relations are incorrectly ignored. Some of these relations are partly in Germany (one node even is) but they should not be ignored.
Relation 6013263
Relation 6013182
Relation 6013181
Relation 6013263
Relation 6013269
Relation 6013268

Link to overview page in navigation panel on the left

At this moment you need a few clicks to get from a certain page to the overview page, while this is one of the most important pages on the website (and the homepage of the old vmarc-site)

I suggest a link in the left navigation panel (where 'Introduction', 'Glossary' and 'Links' are) to the overview page.

Maps too slow at low zoom levels in some browsers

The pages with the hiking map and the bicycle map work OK in Chrome and Firefox browsers on my laptop with the Ubuntu operating system. The same pages are unacceptably slow in Edge and Firefox browsers on Windows 10. At high zoom levels the performance is more or less OK.

Reported by multimodaal (thanks!).

Accessibility of virtual roads (highway=virtual and highway:virtual=*)

A path on a beach or pedestrian square that is not visible in reality, but contains a route can be tagged as a virtual highway. The most common tag is highway=virtual, which is supported by Knooppuntnet because of the usage of the highway key.

This is however a proposal. A different scheme is highway:virtual=*, which includes the actual road type, e.g. highway:virtual=pedestrian. This scheme is not supported by Knooppuntnet, because it doesn't use the highway key.

An example of this issue is this route that uses this virtual way.

It can be solved be adding this rule to the access analyzer for road related networks (hiking, cycling, horse and skating):
way.tags.has("highway:virtual")

And this rule to water related networks (canoe and motorboat)"
way.tags.has("waterway:virtual")

Error 'NetworkExtraMemberNode' doesn't give an error

Node 3417187560 is a member of Wandelnetwerk Getevallei, which is wrong because the actual rwn_ref=16 is just west of this node. So it should raise the error NetworkExtraMemberNode, but it doesn't.

Incorrect facts for route with redundant nodes

Routes that do contain redundant nodes, but for which there is a valid path from start to end node and back, should be marked with RouteRedundantNodes only, and not additionally with RouteNotForward, RouteNotBackward and RouteNotContinious.

Example routes: 12-22, 24-32 and 56-58.

Reported by A67-A67 (thanks!):

In Limburg zijn een aantal routes met veel tussenliggende knooppunten. Deze worden nu onterecht als onderbroken gezien. De fout BijkomendeKnooppunten is natuurlijk wel terecht.

Integrity check for nodes is going wrong

The node facts page for Venlo claims 97 issues with IntegrityCheckFailed. The first, for node 01 says 3 expected, 0 actual. On the node page there are no issues and there are 3 routes connected to the node.

Request: fixme=incomplete routes without errors should be flagged

When a route is not finished yet, the tag fixme=incomplete can be used to marked the route as incomplete. This is a good way to separate those intentionally incomplete routes from the actual, incidental errors that should be solved.

However, sometimes people complete routes without removing this tag. The only way to check this, is to manually check all 842 pages of incomplete routes. I have done this a few times and it is a very tedious job.

My request is that complete routes (without errors, except sorting and wrong-note errors) that are marked as incomplete will result in an error. This would make this check a lot easier.

Junction node not in network is only seen as error in the node list of a network

All junction nodes should be grouped into a network. When one is not added, this is seen as an error in the node list of the network around this node. For example here someone forgot to add junction node 4 to the network relation (I hope it won't be solved quickly, otherwise the example doesn't work). However on the page of node 4 no errors are shown. Besides it is not shown on the overview page.

Because these errors are only shown in the long lists of nodes for each network, it is hard to correct them.

Route incorrectly seen as orphan route

This route is seen as an orphan route in Knooppuntnet. On Openstreetmap it is visible that the route is part of the Velden en Meersen network.

Make map behaviour consistent

This issue repeats #12

I identified 3 map types:

First map type

• has clickable routes and nodes
  
  e.g. https://www.knooppuntnet.be/en/map/rwn

The second map type

• has layer selector in the top right corner
• does not have clickable objects
• shows markers for 1 node when node
• shows markers for start and end node and forward/backward routes when route
  
  
  It can be reached by clicking on map in a url like https://www.knooppuntnet.be/en/node/1333387947

The third map type

• does not have clickable objects
• does not have a layer selector in the top right corner
• shows pointers with nodes belonging to a network
  
  e.g. https://www.knooppuntnet.be/en/network-map/1729060

Opinion: The different map types are a bit confusing, some are missing functionality.

Request: Could the nodes and routes be made clickable on the second and third map style?

Request: Could a layer selector be made available in the third type?

Accessibility skating and horse riding routes

The skating and horse riding routes are always seen as accessible. The following logic should be able to analyze it correctly:

Horse:

  private def horseAccessible(way: Way): Boolean = {
    way.tags.has("highway") ||
      way.tags.has("route", "ferry") ||
      way.tags.has("horse", "yes")
}

Skating:

  private def inlineSkatesAccessible(way: Way): Boolean = {
    way.tags.has("highway") ||
      way.tags.has("route", "ferry") ||
      way.tags.has("inline_skates", "yes")
}

Icons for horse riding and canoeing look zoomed in and low-res

The icons of horse riding and canoeing look like they are zoomed in and not the entire pictogram is shown. When I check on my phone, they are of lower resolution (vague) than the other icons, probably because of the zoom.

Notification in case of malfunction

When everything works as expected there should be new data arriving from OpenStreetMap every minute.

The system should be monitored and a alarm (email message?) should be raised when no new information is processed during for example one hour.

This will prevent situations where a malfunction sometimes passes unnoticed during several days.

Missing translation in summary section in network detail page

The summary section in network detail page does not have a dutch translation for "x nodes". Should be "x knooppunten".

Reported by A67-A67 (thanks!).

[Feature Request] Detect redundant relations

Currently, way 214190421 is part of 4 relations. Relations 3265927 and 6705827 both are part of the same network and carry the same note = 60-298 tag.

Could knooppuntnet provide a warning about this situation. The only current warning is about an incomplete route, while a (different) complete route exists.

Strange lines in routes on map

In the vector tiles there are strange straigth lines between the starting point and some other point in the route, for example in route 72b-78 in hiking network "Dongen".

Many thanks to FrankOverman for reporting this problem.

Add support for routes with loop

Currently, no detailed route analysis is performed for routes that are a loop or contain a loop (where part of the route is re-using the same ways to get back to that start of the route). The route is marked with RouteOverlappingWays and no further analysis is performed.

Example routes: 32-32 and 28-28.

It would be good if the analysis logic could recognize this situation and not issue a fact for this.

Reported by A67-A67 (thanks!).

Please remove network with no name

Deleted relations are not removed from Knooppuntnet

These 3 relations have been removed 8 months ago, because they where doubled from the actual Frylân relation, but they are still shown in the list of hiking networks:

• 7794621
• 7782573
• 7782667

Not very useful overview map of networks

When you take a network map, from https://knooppuntnet.nl/en/networks/nl/rwn or https://knooppuntnet.nl/en/networks/nl/rcn and then use the map icon on top, you get a map with blue markers.
What do these markers do? You can not click them, they only give some very vague idea where a network is.
IMHO it would be a good addition to show some kind of popup with the network name and maybe the status when you hover over a marker and go to the network page when you click on it.

oneway:bicycle=no on roundabout (e.g. with cycleway=track) causes broken route

This route seems to be broken at the roundabout where the route uses a two-way track around the roundabout. The combination junction=roundabout and oneway:bicycle=no implies a two-way roundabout for cyclists. The table doesn't show a 'Yes' in the one way column for these ways. However the route still seems to be broken at this point.

Route 314-353

The analysis of route 314-353 is interrupted because of overlapping ways (marked with RouteOverlappingWays), but that does not seem to be valid logic for this route.

This issue seems to be related to issue #2 where route analysis is also stopped and routes are marked with RouteOverlappingWays.

Reported by A67-A67 (thanks!):

Deze route is een beetje onhandig omdat een way voor de heenweg de ene kant op loopt en voor de terugweg de andere kant op. Ik heb geen idee hoe ik deze route beter kan mappen.

Display option to view map in every screen

The option to view the map is only active in the Nodes screen. This is confusing. You should display this option in every screen when you have a network selected.

Support for inline skating networks

Thanks for expanding to horse, canoe and motorboat networks! But there is one other mode of transportation that uses knooppunten: inline skating. At this moment there is one network in Midden-Delfland, which is also rendered on Waymarked Trails.

The skating network uses the same syntax are cycling networks. To compare both:

• network=rcn <--> network=rin
• rcn_ref=* <--> rin_ref=*
• route=cycling <--> route=inline_skates

Accessibility of canoe and motorboat networks

All canoe and motorboat routes use waterways instead of highways. As the highway-tag is used to check accessibility, all these routes are thought to be inaccessible.

Motorboat routes are accessible when the ways are:

• waterway=*

Canoe routes are accessible when the ways are:

• waterway=*
  OR
• canoe=portage / canoe=yes (used for places where you have to carry your canoe over a dam)

No details of last update in details screen

On the old website there are details of when the relation was last updated and when the website last updated the information from the route relation. The new website does not have this anymore.
It would be helpful if that information was included.

Situation on: 2018-05-12 22:01:02
Network last update: 2018-05-07 Traildino
Relation last update: 2018-01-17 dvdhoven

Enable walking network and horse riding in Germany

There are several walking networks from the Netherlands that pass the German border.
Now these networks have problems with verification as the analysis said there are no walking networks in Germany.
Actually the networks of Twente and Vechtdal have already problems with the expected_rwn_route_relations tag. Several rwn_ref's are reported that they have a wrong number of routes but in fact they have the right number, but some routes are in Germany.
Also the network Bargerveen have problems
The same problem will come in the very close future for horse riding networks.
The network of Twente will pass the German border and in the Grafschaft Bentheim there is a horse riding network already

Please enable walking networks and horse riding networks in Germany.

Thanks in advance

Regards,
Dick van den Hoven

Remove prefixes like 'Sloepennetwerk' from network name

In the cycling and hiking networks 'prefixes' like 'Fietsnetwerk' and 'Wandelnetwerk' are removed from the network name. This way all networks are sorted at the important part of the name.

Example: Fietsnetwerk Haaglanden has the tag name=Fietsnetwerk Haaglanden, but the page title is 'Haaglanden' and the network is sorted at the 'H' in the network list.

This however doesn't work for horse, canoe and motorboat networks.

The prefixes in use are:

• Horse: Ruiternetwerk, Ruiterroute and Ruiterroutenetwerk
• Canoe: Kanonetwerk
• Motorboat: Motorbootnetwerk and Sloepennetwerk

Deleted networks still flagged active

The network relations of following networks have been deleted from the OpenStreetMap database:

• 7782573
• 7782667
• 7794621
• 8201192
• 8188961

The expectation is that these networks get flagged in the analysis database with active=false , and that a NetworkChange object with change type DELETE is added to the network history. This does not seem to have happened, or is not properly reported in the userinterface.

Many thanks to Maarten Deen for reporting this problem.

Hiking network Brabantse Wal sorted before ' and A

For some reason the hiking network Brabantse Wal is sorted at the first place in the Dutch hiking network list, before the apostrophe and A.

Oneway route seen as broken twoway route

The routes below have been mapped with the tag 'direction=backward', because only the backward direction can be used. Knooppuntnet recognizes this tag, but thinks it is an broken twoway route, that has been mapped incorrectly as oneway route.

The route strip shows that Knooppuntnet thinks that the first way is a part of the forward route, instead of the backward route, although it is mapped correctly.

• 60-61
• 63-64

Nodes and routes page only show a few items at a time

The nodes and routes pages only show 25 items at a time. Since these are long lists and you sometimes need a node or route at the end and because it is much more convenient to check for anomalies, it would be better to at least have an option to have all items on one page.
Having only a previous and next is also inefficient navigating when you sometimes have 30+ pages of nodes.

Deleted network nodes still analyzed and seen as orphan nodes

The network nodes below are not network nodes anymore (rwn_ref is removed), but they are still analyzed. Therefore they are incorrectly seen as orphan nodes:

• https://knooppuntnet.nl/nl/node/6234320214
• https://knooppuntnet.nl/nl/node/6234320386

Accessibility of canoe and motorboat routes seems still wrong

Thanks for adding the accessibility analysis of canoe and motorboat routes in 2.0.10. However, still all routes are seen as inaccessible:

• https://knooppuntnet.nl/nl/RouteUnaccessible/nl/rpn
• https://knooppuntnet.nl/nl/RouteUnaccessible/nl/rmn

The source code looks good, so it is quite strange.

No facts are shown

https://knooppuntnet.nl/nl/network-facts/2240269

On the left after facts it says 68, the old site also show these facts (mostly nodes where the integrityCheckFailed "expected_rwn_route_relations" failed) but the main screen says "Venlo
Facts
no facts"

Add support for one-way routes

There are networks that contain some routes that are intended to be used in one direction only. Currently these routes are marked with RouteNotForward (GeenHeenWeg) or RouteNotBackward (GeenTerugWeg), depending on which direction the analysis logic thinks is missing.

It would be good to accept these routes during analysis.

Example routes include: 62-72, 63-64 and 63-71.

Currently these routes are marked with a tag "comment" that includes the text "to be used in one direction". Perhaps one could agree to tag these routes with for example "oneway=yes" or "direction=forward|backward".

This was reported by A67-A67 (thank you):

De fouten in het netwerk "Le Brabant wallon à vélo" komen doordat er routes zijn die maar in één richting lopen. Voor de terugweg moet je via andere routes. Dit komt nog op meer plekken voor, maar daar is de terugweg, eigenlijk foutief, via een ander knooppunt getagd. Deze routes staan nu bij de BijkomendeKnooppunten-fout. Misschien is een oneway=yes of direction-tag een oplossing voor dit soort routes. Dat moet eigenlijk eerst op het forum besproken worden.

Route analysis fails when route contains way with one node only

On May 31th, the analyzer stopped (last successful analysis at 19:04). Simply restarting the analyzer did not help.

Investigation learns that the analyzer logic tripped over a route (2941800) wich contains a way (207342401) with a single node only. The code incorrecly assumes that a way always contains at least 2 nodes.

The code will be changed to ignore ways without nodes or ways with one node only.

Thanks to Noël and Frank for reporting this problem.

Error on page of route 28-40 (relation 6395727)

Extra information in note-tag, separated by semicolon, works only some cases

In JOSM only the note-tag is shown for a relation. The note-tag normally contains the numbers of both junction nodes. This is fine in most cases, but there are moments when you would want more information in the note-tag, mostly when there are two relations between junction nodes. Another example are motorboat and canoe networks that use the same numbers for junction nodes. Then you wouldn't know whether 4-5 or 4-5 is the canoe route.

Separating this extra information with a semicolon seems to work in some cases. For example 4-5; canoe is seen as Route 4-5

However in other cases this doesn't work. 63-64; canoe north stays Route 63-64; canoe north and 26-30; canoe; oost stays Route 26-30; canoe; oost

Node at opposite end of route with role "connection" not to be added to network relation

The general rule is that the start and end nodes of all routes in a network should be added to the network relation. An exception to this rule is for nodes in routes with the role "connection". These routes form a connection to another network. The route end node of the "other" network should not be added to the route relation of "this" network.

See network relation tagging in OSM wiki:

Do not add the junction nodes of the opposite end of routes with role=connection, as those are members of another network.

Currently the analysis logic flags the node at the opposite end as not OK:

NOK - Not defined in network relation
This node is not included as a member in the network relation. This is not ok. The convention is to include each node in the network relation.

This is wrong.

Reported by A67-A67 (thanks!):

Bij een verbinding tussen netwerken wordt het knooppunt over de grens niet in het netwerk opgenomen. Dit wordt nu als fout gezien. Even een voorbeeld: Hier wordt het als fout gezien dat knooppunt 08 niet in het netwerk Geldrop-Mierlo zit, terwijl bij de routes wel staat dat 08-64 een verbinding is. Daarom hoort knooppunt 08 bij Eindhoven en 64 bij Geldrop-Mierlo.

Deleted network Brabant doesn't disappear

Someone made a hiking network relation for Noord-Brabant, while those routes should be in network relations per municipality. I deleted the network, but it is still in Knooppuntnet including the errors.

Deleted network back in analysis

The network Knopenlopen Sevenum has been deleted 4 years ago, but it is being analysed since a short time. This includes a lot of errors that have been solved years ago.

Map zoomed out when navigating back

This is a repeat of #11 (discovered after editing this issue)

After opening a map, then carefully zooming in to a location, then clicking on a route/node and choosing more details, a route / node details screen is shown.
Fact: Navigating back in the browser returns to the map in zoomed out view
Opinion: I would really prefer to keep the previous zoomed in location, where I left the map.
Fact: There is a workaround: holding Ctrl down while clicking "more details" to open the details in another tab and keep the #map.
Fact: Using the MAP navigation on top, next to the language navigation, brings us to a map, but nodes and routes are not clickable on that map. So that map cannot be used as workaround.

Map with clickable routes/nodes:

When returning to map:

This map does not have clickable routes/nodes:

Allow nodes with "tourism=information" + "information=guidepost" in routerelations

In Germany there are a lot of routes that contain nodes tagged with information=guidepost and tourism=info (example route 01-02). The current analysis logic results in more than 700 routes that are marked with RouteUnexpectedNode (OnverwachteKnoopInRoute).

It would be better if this type of nodes is allowed in routerelations.

Reported by A67-A67 (thanks!).

Remember map position and zoom level

When navigating to node or route details from the main map, and afterwards returning to the main map, it would be handy to return to the same position and zoom level on the map, rather than totally zoomed out as it is now.

Thanks to Maarten Deen for the suggestion.

Node numbers in web page title

In the old VMarc the node numbers where shown in the title (e.g. on the tabs in your browser). To solve errors, I used to open all similar errors in a network in new tabs. It was then easy to see which tab was which route. In the new Knooppuntnet.nl however only the name 'knooppuntnet' is shown in the title.

Example:

• Old: Route 02-04 - Asten
• New: knooppuntnet

I would prefer when the node numbers where shown at the start of the title, like '02-04 - knooppuntnet' or '02-04 - Asten - knooppuntnet'. The word 'Route' is not necessary as all routes start with two numbers and when a lot of tabs are opened, only the word Route would be visible.