Morocco Route Nationale (marn)

[panda80]

MAR N16:

N16_E --> A5_E (or A5_KsaN?); alt label required

Why put an alt Label on N16? It's not yet possible for someone to have mileage there.

ToCeu: The route to Ceuta is indicated "N13" on GM but not on OSM. Any idea about the actual status? I guess N13 is outdated (the different N16 routing to the south on GM too)

Yes, these are reminiscent from the old numbering.

MAR N17:
I think P1522 is totally off, isn't it?

By zooming out or deep zooming in, is the point where I placed it.

MAR/MRT --> ESH/MRT

According to Si, is MAR/MRT correct. You also accepted his point of view.

[michih]

MAR N16:

N16_E --> A5_E (or A5_KsaN?); alt label required

Why put an alt Label on N16? It's not yet possible for someone to have mileage there.

For A5, not for N16

MAR N17:
I think P1522 is totally off, isn't it?

By zooming out or deep zooming in, is the point where I placed it.

IS http://www.openstreetmap.org/?lat=30.060254&lon=-6.869416
SHOULD_BE http://www.openstreetmap.org/?lat=30.060388&lon=-6.869387

MAR/MRT --> ESH/MRT

According to Si, is MAR/MRT correct. You also accepted his point of view.

Yep, but I've posted it before I've edited the original post now.

[panda80]

IS http://www.openstreetmap.org/?lat=30.060254&lon=-6.869416
SHOULD_BE http://www.openstreetmap.org/?lat=30.060388&lon=-6.869387

Ok, I thought you were reffering to the other position, more to the NE, which is shown by OSM at some zoom levels.

[panda80]

N25_N --> N25_E

N25 is for me a N-S route.

MAR N29:

Move +X9 a little bit to the north

First round of review done.

Thank you. Implemented the changes, will come with the next pull request.

[panda80]

System is now in preview.

[michih]

1. I recommend adding a shaping point on N1 south of A501 wp so that A501 and N1 can be distinguished on mapview. It currently looks like being concurrent.

2. N8/N29 concurrency is broken north of P7308 (both shaping points need to be synced)

3. N10/N13 concurrency is broken (N13 wp N10_W needs to be moved to N10 wp N13_N location)

4. A3 end point label needs to be corrected: +N8_D N11/N11A --> N11/N11A +N8_D. It's an invisible wp which cannot be browsed right now: http://travelmapping.net/hb/index.php?r=mar.a003

5. N7/N10 concurrency is broken west of P1731

6. Additional N11 segment b/n A101/N1 and A3?

@panda80, I recommend you exploring HDX to see how you can find the issues.
I used Option 1 "Search for a METAL graph by name." to find all issues but you can also download mar.nmp from here and upload to HDX by option 3 to find NMPs. You might find issue no. 2, 3 and 5 this way much easier.

http://travelmapping.net/devel/datacheck.php?sys=null&rg=MAR

The HIDDEN_TERMINUS error for A3 and the VISIBLE_HIDDEN_COLOC for N11 are caused by issue no. 4
The HIDDEN_JUNCTION erros should be caused by the broken concurrencies but I'm not sure.
The DUPLICATE_LABEL errors should be clear, just change the names.
Please check all SHARP_ANGLE errors manually but I guess all should be on purpose and can be marked FP. Copy the content of the "FP Entry to Submit" column to datacheckfps.csv after checking the situation with wpt editor
The same for LONG_SEGMENT errors. Check that they are on purpose and mark them FP.
VISIBLE_DISTANCE errors can generally be ignored here.

All tools can be found here: http://travelmapping.net/devel/tools.php

If there's any question, just ask

[michih]

http://travelmapping.net/devel/datacheck.php?sys=null&rg=ESH

The N1 LABEL_SELFREF error needs to be marked FP too.
Other errors are handled like the MAR issues mentioned above.

[michih]

Another issue is the system name. I've changed system.csv (I've enter wrong by accident) and systemupdates.csv entries to "Morocco Routes Nationales" like mara and fran system names.

[michih]

You've added N11Cas and N11 needs a "city" name now. I think there is no relevant city describing the route fine. I would add (Main).

[michih]

I think that the system is ready for activation. Any objections?

[michih]

System is active now.

Congrats! First system activated, panda80!

[panda80]

Congrats! First system activated, panda80!

Thanks a lot for your help

[yakra]

Please check all SHARP_ANGLE errors manually but I guess all should be on purpose and can be marked FP. Copy the content of the "FP Entry to Submit" column to datacheckfps.csv after checking the situation with wpt editor
The same for LONG_SEGMENT errors. Check that they are on purpose and mark them FP.

I'm a bit late to the party here, but LONG_SEGMENT errors are a different animal from VISIBLE_DISTANCE, hence having their own datacheck category. The original idea was to have these be an "always a true error" datacheck type. These would have shaping points added to break up long segments so that all segments are < 20 miles, whether visible or not.
(There's also one example in tur.d350.)

[michih]

LONG_SEGMENT errors are a different animal from VISIBLE_DISTANCE, hence having their own datacheck category. The original idea was to have these be an "always a true error" datacheck type. These would have shaping points added to break up long segments so that all segments are < 20 miles, whether visible or not.
(There's also one example in tur.d350.)

I was not yet on board when LONG_SEGMENT errors were declared being "always a true error" and I don't see any point why they should be. There are very long segments through the desert without any potential wp and breaking the segment up by a hidden wp makes no sense to me since marking it FP - as for all other data errors - works fine. There are currently not data errors: http://travelmapping.net/devel/datacheck.php?sys=marn
Maybe the hidden wp thing was the only way to get approval from Tim?

[yakra]

I was not yet on board when LONG_SEGMENT errors were declared being "always a true error" and I don't see any point why they should be.

Thinking about this some more.
This was really just to aid in the old CHM map-drawing engine, and is not really relevant any more for TM, with the switch to interactive maps.
The idea was to avoid long segments that would not have been plotted due to crossing completely over a given viewport / bounding box without having any points within it.
For example, the Portland map would have looked more or less like this one (generated with https://github.com/yakra/tmtools/tree/master/canvas),

except that the small segment of ME35 crossing over the SW corner was left out.

So we can see that even with the datacheck included, we still weren't always guaranteed proper results.

Less of a big deal because there's little to no need for the small city/area maps, with the interactive Leaflet maps.
A region map will by definition contain every highway segment in that region.
Less of a big deal because even if we don't see TM routes in a neighboring region when looking at a region map, we at least have OSM & other tilesets to get our bearings & some context.
Even if we did add routes within a bounding box for a given region, I wouldn't cry about missing a route segment from my MA map in a faraway corner of CT or NY.
Doing such, or re-adding CHM style maps seems unlikely. Especially with the variation in viewport sizes due to different screen resolutions / window sizes, it'd be too complicated code for too little gain.

TLDR; I'm fine with leaving these marked FP as they currently are.
Might even be open to a discussion about potentially removing that datacheck altogether.