Travel Mapping
Highway Data Discussion => In-progress Highway Systems & Work => Topic started by: nezinscot on April 06, 2021, 12:34:55 pm
-
All of my driving in Japan has been on the national highway system and on prefectural roads, not the expressways. I wanted to add this mileage but did not find a highway system for the "common" national highways.
Is anyone working on a highway system for the 55000+ km of national highways? If no one is and you all feel the system is needed, I would be willing to help with the task.
I speak, read, and write intermediate level Japanese and would be willing to use this painfully acquired skill to dig through the ministry websites and GIS systems for original sources. I am also familiar with the problems related to Japanese street naming and addresses. The file creation and manipulation part of the task shouldn't be a problem because I spent years working in science and engineering-related IT.
The work would also help me improve my Japanese. I was definitely never taught highway-related vocabulary in class...
-
Great news :) si404 developed the existing systems. I think he will answer what he thinks about it.
General note:
The requirements for developing new systems are described here: https://travelmapping.net/participate.php?u=michih&#hwydatamanager
When you reach stage 5 (I guess you are currently at stage 3?), jpntk and jpne could be your candidates for the peer-review:
https://forum.travelmapping.net/index.php?topic=3004
https://forum.travelmapping.net/index.php?topic=3668
I started the jpne system peer-review last May but gave up quite soon and will not work on it again any time soon.
-
I'm at level 4. I read the developer manual before I volunteered so that I could have an idea of what the work might entail. I no doubt need to give it another close reading.
Japanese numbered highways have some interesting quirks --- most intersecting roads are nameless, roads can span multiple islands, mountain roads can use widely divergent paths for each direction, roads may have two options (one a new tunnel the other the old twisty mountain road), ridge roads often wind back and forth across prefectural borders, etc. At least the GSV coverage is good.
There are 47 prefectures, so a complete Japanese system would be a mini-US. And if we include the extensive train and metro systems, the task gets even bigger.
-
I have almost completed my review of the Japanese expressway systems and would like to work on the Japanese national highway system next.
There are 400+ national highways in Japan, plus hundreds of related bypasses and older routes that are still considered part of the national highways. In all there could be ~1000 separate entries in this new system. I believe we are trying to create smaller systems, so if I started this work, I would like to create separate systems for each prefecture (province). There are 47 prefectures.
Separate systems for each prefecture will also help deal with the abundant duplicate prefectural road names found on the longer national highways. For example N4, the longest national highway, intersects P8 and P25 in four separate prefectures.
There is information online about the newer parts of the national highway system, especially the bypasses around towns. GSV coverage is very good in urban areas and adequate in rural areas. Highways are usually well marked with route and mileage markers. Plus there are enthusiast websites in Japanese that cover the routes in detail, for example http://hgf03030.a.la9.jp/index.htm.
I would like to know if you all consider this a project worth doing.
-
I believe we are trying to create smaller systems, so if I started this work, I would like to create separate systems for each prefecture (province). There are 47 prefectures.
Separate systems for each prefecture will also help deal with the abundant duplicate prefectural road names found on the longer national highways.
I think that we can go with smaller systems through the development process as we did for gbna or deub but the systems should be merged on activation. However, we should not do it by prefectures since the routes (wpt files) would need to be changed. This would affect users.
For example N4, the longest national highway, intersects P8 and P25 in four separate prefectures.
There is a simple solution: https://travelmapping.net/devel/manual/wayptlabels.php#over2
I would like to know if you all consider this a project worth doing.
I think so! We have 7 users with travels in Japan so far. We have regions or systems with less travelers.
-
I'll follow your advice about using devel-only systems to split up the work.
I think jpnh should be the system name for the national highways.
Devel-only systems can be used for each island, or island section for Honshu. They can be swept into jpnh as they are completed.
jpnhky - Kyushu and Okinawa
jpnhsh - Shikoku
jpnhhk - Hokkaido
jpnhkt - Kanto (east Honshu / Tokyo)
jpnhks - Kansai (west Honshu / Osaka)
I was thinking that jpnh would be type 3, but I see that US national highways are type 2. Would type 3 be the better choice? Japan already has systems for type 1 and 2.
-
I was thinking that jpnh would be type 3, but I see that US national highways are type 2. Would type 3 be the better choice? Japan already has systems for type 1 and 2.
It should be tier 4 like the other national highway systems in Asia (and Europe) but the Indian one is tier 3 (https://travelmapping.net/hb/index.php?sys=indnh) - likely a mistake.
-
Just a note on N295:
https://travelmapping.net/hb/showroute.php?r=jpn.n295
https://travelmapping.net/hb/showroute.php?r=jpn.e065
- E51/E65 must be a one-point-per-interchange with E65's N295 wp
- E51/E65 might even be a one-point-per-interchange with E65's exit 10 + N295 wp
- E51/E65 does not (directly) connect to E51. Wp should be called E65_something
- NarApt must be a one-pont-per-interchange with E65! I tend to adding a wp to E65 at NarApt location.
-
N481
While deep into some shell scripting, I found E71(4)/P29 which led me here.
This would want to have either the E71(4) or the P29, but both isn't really something we do.
Avoid using two designations and a parenthetical suffix in the same label.
For the coordinates, I'd recommend moving the point in E71's file to match (https://forum.travelmapping.net/index.php?topic=3004.msg25501#msg25501).
Back to the label, what to do here... I guess I'd recommend E71(4), as this is where the multiplex would end anyway if Exit 3 weren't right up in the mix being all confusing. It fits in with with E71(5) and E71(3).
Reposition E71(3) to sync up with the point on E71 (https://travelmapping.net/hb/showroute.php?r=jpn.e071&lat=34.412327&lon=135.296888&zoom=17) and get concurrency detection working.
E71(5) is fine.
E71(2):
Wow. This is like some of the crazier parts of urban Texas. I don't envy you having to sort this out right when joining the project.
When plotting out points on these complex frontage road systems, I find it helps to ask where the points would fall if the frontage roads weren't in the picture, if the connections were made via traditional diamond ramps or equivalents.
On freeways/expressways, this usually results in point placement at a major central crossroad (often at another route in the HB if there is one) for diamond equivalents.
Half-diamond equivalents will usually be the first crossroad. The first one with a bridge, unless such is really far away. If there are multiple grade-separated crossroads close together where the ramps touch down, and a major route (also in the HB) isn't the very first one, I might still pick that sometimes, and get a graph connection.
Thus IMO JPN E71 2 (https://travelmapping.net/hb/showroute.php?units=miles&u=si404&r=jpn.e071) is placed appropriately, centered at N26.
So E71(2) and N26, we'd want to collapse into One Point Per Interchange. Putting it at the same coords as on E71 will give a graph connection with E71 now; I presume N26 will be drafted in the future. Right now N481's file has more precicse coordinates, so I'd recommend replacing the coords in E71's file with those.
As for whether to name this point E71(2) or N26, I'm agnostic; won't push for one over the other. This reminds me of TX US183 at TX21 (https://travelmapping.net/hb/showroute.php?r=tx.us183&lat=30.027758&lon=-97.687909&zoom=15), though I won't necessarily say what I did there is The Right Thing To Do.
-
Thank you both for the reviews.
I have mostly followed your advice and have modified both the national highways and the national expressways. Here are the changes I plan to submit. I'm not convinced what I did with E51(10) on N295 is right, but I wanted to include the connection to E51.
https://github.com/TravelMapping/HighwayData/compare/master...denishanson:master
Should I be the one to make the changes to the E65 and E71?
-
Is there an accepted process for promoting a system in multiple steps from devel to preview?
I have created jpnh plus five devel-only system for the Japanese national highways, splitting the country by islands. Should I push jpnh now to preview and sweep the other systems in individually once they are completed in devel?
-
Is there an accepted process for promoting a system in multiple steps from devel to preview?
Just check out systemupdates.csv (https://github.com/TravelMapping/HighwayData/blob/master/systemupdates.csv), e.g. here (https://github.com/TravelMapping/HighwayData/blob/master/systemupdates.csv#L289), here (https://github.com/TravelMapping/HighwayData/blob/master/systemupdates.csv#L447), here (https://github.com/TravelMapping/HighwayData/blob/master/systemupdates.csv#L543), here (https://github.com/TravelMapping/HighwayData/blob/master/systemupdates.csv#L563) or here (https://github.com/TravelMapping/HighwayData/blob/master/systemupdates.csv#L674).
-
I'm not convinced what I did with E51(10) on N295 is right, but I wanted to include the connection to E51.
https://github.com/TravelMapping/HighwayData/compare/master...denishanson:master
Oh man. Another screwy interchange. Looking at N295 alone, it seems to have a clear center. But getting a sensible graph connection at E65 seems to beg for a point right where you have it now.
E51(10) matches this sign (https://www.google.com/maps/@35.7835235,140.3542255,3a,15y,94.07h,99.99t/data=!3m9!1e1!3m7!1soCrh9uxv5fuXP4iY9ZKlKA!2e0!7i16384!8i8192!9m2!1b1!2i40), though there's no other E51 waypoint, so the exit number suffix should be dropped. ..."E51" offends my sensibilities, as it directly connects to E65. ;) Disambiguating multiple "E65" points? That could get messy too.
The more I look at this the more 1PPI (labeled E65) seems the way to go.
Then it becomes a matter of balancing the competing goals of a central point location vs. having a sensible graph connection point.
There's the "central ramp triangle" (http://www.openstreetmap.org/?lat=35.782559&lon=140.354963&zoom=19) approach the manual suggests (https://travelmapping.net/devel/manual/points.php#three_way) (which I'm not always a fan of); may be possible to weasel one's way out of it (like maybe even here (http://www.openstreetmap.org/?lat=35.782276&lon=140.355371&zoom=19)?) on "this ain't exactly a 3-way high-speed interchange" grounds?
Should I be the one to make the changes to the E65 and E71?
Check with si404; dunno whether he'd prefer to make the changes himself or be OK with you doing it.
-
Should I be the one to make the changes to the E65 and E71?
Check with si404; dunno whether he'd prefer to make the changes himself or be OK with you doing it.
I'm fine with this.
There's not much left of the jpntk review to do, once that's done, I'll activate my systems in Japan and hand over maintenance.
-
All routes for the islands of Kyushu and Shikoku have been added. Honshu is next.
What I've learned so far:
-- Routes are averaging about 2.5 entries per route number, so I anticipate the entire system will have 1000+ entries.
-- Japan is mountainous so roads curve a lot. Route lengths can be 20% less than the official route length.
-- To keep the waypoint count reasonable, I tend to only include expressways, national highways, and most but not all principal prefectural roads (主要地方道, usually they have numbers less than 100).
-- Routes are averaging a waypoint every 2 miles or so.
-- Determining whether a section of road is the main route, a bypass, or an old road (original route) can be difficult. Maps cannot be trusted. GSV can only be trusted if the data is very recent.
For Honshu, I've decided to do the worst first, so I have starting working on N1 - the Tokaido. It now bears no relationship to the Tokaido of woodblock prints. Its a 500km version of US1 through northern New Jersey, but with more trucks and stoplights.
I've found a lot of sections where N1 runs beneath an expressway, connecting with the overhead expressway at a series of ICs. How do I prevent concurrencies between N1 and the expressway? Add routing waypoints to N1 between the ICs? Nudge the N1 waypoints over a little, causing NMPs?
-
I've found a lot of sections where N1 runs beneath an expressway, connecting with the overhead expressway at a series of ICs. How do I prevent concurrencies between N1 and the expressway? Add routing waypoints to N1 between the ICs? Nudge the N1 waypoints over a little, causing NMPs?
Just add a visible (or hidden) wp to one of the routes to break the concurrency.
We often implemented another option in the past by moving one wp off for a route by 0.000001° to get a NMP. However, since we show intersecting routes in the HB, we should not implement this anymore.
-
I've found a lot of sections where N1 runs beneath an expressway, connecting with the overhead expressway at a series of ICs. How do I prevent concurrencies between N1 and the expressway? Add routing waypoints to N1 between the ICs? Nudge the N1 waypoints over a little, causing NMPs?
Either of those should work; I'm not sure what is the preferred method.
-
I've found a lot of sections where N1 runs beneath an expressway, connecting with the overhead expressway at a series of ICs. How do I prevent concurrencies between N1 and the expressway? Add routing waypoints to N1 between the ICs? Nudge the N1 waypoints over a little, causing NMPs?
Either of those should work; I'm not sure what is the preferred method.
Definitely adding shaping points between interchanges at this point for more graph connections. I think a past example of nudging waypoints over a little can still be seen on I-65/US 31 in Indiana just north of Louisville.
-
Thanks for the info. I have been using hidden waypoints, so I will continue to do so. I was concerned because in a few cases I have had to add hidden waypoints between every IC.
I have another complication with expressways over surface roads. Expressway E89 between Osaka and Kyoto is also a bypass of N1. E89 is a toll road and the surface road beneath it, also labeled N1 is free. The surface road has many additional waypoints. Should I make two separate N1 entries for the bypass.
And it gets more complicated. E88 is also an N1 bypass. The surface road beneath it, also marked N1, is only present at the ends of E88 (there is a long tunnel between). Plus the west end surface road marked N1 begins west of the west end of E88, and the east end N1 surface road continues past the east end of E88. Are there three N1 bypass entries here?
-
I've found a lot of sections where N1 runs beneath an expressway, connecting with the overhead expressway at a series of ICs. How do I prevent concurrencies between N1 and the expressway? Add routing waypoints to N1 between the ICs?
I'd recommend this.
-
yakra, how did you decide on what to do in regards to Toll 183 vs US 183? Are both truly part of US 183?
-
Not sure if you meant to post that in another thread.
Toll 183 is not included. None of the TX toll routes paralleling a same-numbered route in a mainline/frontage setup are.
-
Not sure if you meant to post that in another thread.
Toll 183 is not included. None of the TX toll routes paralleling a same-numbered route in a mainline/frontage setup are.
I was just wondering how related that could be to nezinscot's situation. It probably is not, but it sounds similar.
-
There are other cases. First that comes to mind is US183 & TX130.
I broke up the not-concurrencies with shaping points via a custom tool (https://github.com/yakra/tmtools/tree/master/autoshape).
That might be a bit rich for most people's blood; another option for keeping the divergences to a minimum is to double-click on the existing polyline in wptedit to center before adding a new point.
-
I'll follow your advice about using devel-only systems to split up the work.
I think jpnh should be the system name for the national highways.
Devel-only systems can be used for each island, or island section for Honshu. They can be swept into jpnh as they are completed.
jpnhky - Kyushu and Okinawa
jpnhsh - Shikoku
jpnhhk - Hokkaido
jpnhkt - Kanto (east Honshu / Tokyo)
jpnhks - Kansai (west Honshu / Osaka)
Why don't you bring your systems to preview status? I mean, the basic idea of splitting systems during development phase is that we can promote it earlier to preview and make it visible (stats, mapview) for users. If you think that "jpnhky" is complete (https://github.com/TravelMapping/HighwayData/pull/5423), it should go to preview (https://travelmapping.net/devel/manual/sysnew.php#preview)!
-
I was waiting for a second pass thru the systems but that is likely a long way in the future because doing Honshu is a big task. So, I will take your advice and promote the pieces that are done. Should I only promote jpnh to preview and fill it with what is done, or should I promote all the completed systems?
-
I was waiting for a second pass thru the systems but that is likely a long way in the future because doing Honshu is a big task. So, I will take your advice and promote the pieces that are done. Should I only promote jpnh to preview and fill it with what is done, or should I promote all the completed systems?
I don't understand why you already have a jpnh system in devel. I thought that you've split the future system into individual systems per island. The individual systems can be promoted to preview status when they are complete. Incomplete systems should stay in devel (except of special "select systems" we don't have in Japan). Once all individual systems are complete, you can merge the systems into one again.
-
jpnhky - national highways in Kyushu and Okinawa - is now in preview mode.
83 highways / 215 routes
4564 miles
If you were ever stationed at Sasebo or in Okinawa you probably have driven some of these roads.
-
N329BypHae
There's only one intersection with E58, so E58(A1) should become E58 or E58/N506.
WRT Byp as a banner, is this appropriate? The route may functionally be a bypass, but a banner should really only be included if it's an official part (usually signed) of the designation. If Japan does use (and sign?) such a designation, what's the JP word they use?
(Just watch it be English...)
-
I will update the E58(A1) waypoint name to E58.
As for bypasses, its complicated, like many things Japanese. Almost every expressway and many urban national highways in Japan are built from a set of connected "bypasses". A new section of road usually has its own bypass name. They actually use the katakana version of the word "Bypass". What we would consider a bypass in the US will also have bypass in its name. I spend a lot of time trying to figure out what the bypass name of a road segment is because most online info uses the bypass name and not the national highway designation.
I've done about 60% of the national highways so far, and have identified four types of road segments.
1) The current road (the main line). Originally the national highways went right through towns, but over time bypasses have been built to widen the road or avoid town centers and other obstacles, and the current road moved to the bypasses.
2) Old roads. When the original route is replaced by a bypass, usually the old route is transferred to the prefecture or city and given a local designation. (This transfer may take several years, so new bypasses are often associated with "temporary" old road sections.) But in some cases, the original route retains it national highway designation, so there are two routes with the same designation.
3) Bypasses. These are built usually to avoid town centers or other areas of heavy traffic. They are not old roads and they are not the current road. They often connect at both ends with the current road or another national highway. I believe "Byp" is the correct banner for these roads.
4) Spurs and connectors. They connect the current road, old road, or a bypass to another road, often an expressway.
There is some degree of ambiguity. Sometimes its tough to determine which is the current road and which is the bypass, or which is the current road and which is the old road. True bypasses and spurs are usually pretty obvious.
Japan does not sign its bypasses, old roads, or spurs any differently than it does current roads - they all get the blue rice ball sign with a number on it. Sometimes an overhead sign will indicate which route is the bypass, or the old road, but this is not prevalent.
There are also national highway bypass designations on many expressways, typically those that are free and were built with prefectural money. These bypasses usually do not have national highway signage because in general, Japan does not multi-sign concurrencies.
-
They actually use the katakana version of the word "Bypass".
LOL figures. Works for me!
バイパス!
(...or would that be バイパツス?)
グーグル翻訳 seems to like the ichiban one. :D
-
バイパス (baipasu) is the word used.
I updated N329BypHae to use E58.
FYI - On March 6th the entire Yonabaru bypass will open and N329BypHae and N329BypYon will then connect.
-
I'm thinking of splitting the national highways into three systems because of the size of a single system containing everything.
jpnh - current roads, spurs, and connections
jpnhby - bypasses
jpnhor - old roads
If compared to the US systems, jpnhby are the Alt routes and jpnhor are the Bus routes. jpnh and jpnhby would each have ~550 entries. jpnhor might reach 75 entries.
Do you think this division would be preferable to having a single system of 1200 entries?
And I would like to eventually add the very extensive railway system. Most of my and other visitors' travelling in Japan uses the railroads.
-
I'm thinking of splitting the national highways into three systems because of the size of a single system containing everything.
jpnh - current roads, spurs, and connections
jpnhby - bypasses
jpnhor - old roads
If compared to the US systems, jpnhby are the Alt routes and jpnhor are the Bus routes. jpnh and jpnhby would each have ~550 entries. jpnhor might reach 75 entries.
Do you think this division would be preferable to having a single system of 1200 entries?
Do your "systems" have different signs? How can one distinguish them?
The number of routes is not a relevant argument.
And I would like to eventually add the very extensive railway system. Most of my and other visitors' travelling in Japan uses the railroads.
You can draft it but we need a new (or enhanced) database and front end before getting them live. I highly doubt that anyone would code it anytime soon. There are already prepared US railway systems (https://github.com/TravelMapping/HighwayData/tree/master/rlwy_data).
-
btw: Are you interested in implementing a system shield (svg file) (https://travelmapping.net/devel/manual/sysnew.php#developshield)?
-
A single system of 1200 routes would be better -- usaus & usausb are, tmk, the only instance of bannered routes split off into their own system. Everything else has bannered & mainline together in the same system. They were the first two systems developed for the old Clinched Highway Mapping project after Interstates (both regular & business), before how these things are done got nailed down. If US Highways were to be drafted today, they're surely be as a single system, including bannered routes.
-
Thanks for all the feedback. One system - jpnh - will contain everything.
I plan on creating system shields for jpne and jpnh. There is no one shield that works for jpntk. Each regional system may need its own shield. Is it easy to associate a shield with some but not all routes in a system?
I'll revisit the railroad system later. (By the way, I used to develop Javascript-based web GUIs that allowed users to design their own UIs using DnD. I know SQL but only enough to sort of follow yakra's musings.)
-
Is it easy to associate a shield with some but not all routes in a system?
It's doable but not easy - not as simple as we deal for other systems.
btw, if we have different jpntk shields per region, why don't we have one system per region?
I'll revisit the railroad system later. (By the way, I used to develop Javascript-based web GUIs that allowed users to design their own UIs using DnD. I know SQL but only enough to sort of follow yakra's musings.)
You might want to check the dedicated thread for railway systems :)
-
Here's a GitHub Issue that's probably relevant to the shields discussion (https://github.com/TravelMapping/Web/issues/614).
-
jpnhky_con.csv:
jpnhky;N497;;Nishi Kyūshū Expwy Sasebo section (E35);jpn.n497
jpnhky;N497;;Nishi Kyūshū Expwy Sasebo section (E35);jpn.n497fuk
These two routes have the same GroupName data, and should be named differently.
Also, recommend removing the "(35)". Looks like that just refers to a concurrent route, something that's not done elsewhere.
-
Cut-n-paste error. n497fuk should be Fukuoka section.
The fix will be submitted later today.
I will also remove "(Exx)" from group names. (Kyushu only, I'll do the others the next time I access them.)
-
I will also remove "(Exx)" from group names. (Kyushu only, I'll do the others the next time I access them.)
Neither "section" nor "Expwy" etc. should be used.
https://travelmapping.net/devel/manual/syshwylist.php#conncname
Use geographical names, e.g. city names, island names or country names.
-
Working on some changes (https://github.com/TravelMapping/DataProcessing/issues/528) to the waypoint simplification routines for the graph generation process, some diffs in waypointsimplification.log (https://travelmapping.net/logs/waypointsimplification.log) (20 MB file -- you probably don't actually want to click the link! ;)) led me here.
The banners and/or abbrevs in some waypoint files mismatch the .list names of the files they connect to:
| in file(s) | point label sans suffix | corresponds to |
| N49, N459 | N49OldMik | N49Mik |
| N49, N459 | N49OldTsu | N49Tsu |
| N121 | N121OldIka | N121Ika |
| N121 | N121OldOku | N121Oku |
| N121 | N121SprKin | N121Kin |
| N16 | N17BypSom/N17BypAge | N17BypAge, N17BypOmi |
| N126 | N126OldIna | N126Ina |
| N55, N195, N438, N439 | N192BypTok | N192BypToE |
| N192, N318 | N192BypTok | N192BypToW |
| N492 | N439BypSug | N439, N439Yas |
| N32 | N32SprKoc | N32Koc |
| N56 | N56OldMas | N56Mas |
This is probably not an exhaustive list. Only locations with 3+ waypoints were captured.
The route+banner (https://travelmapping.net/devel/manual/wayptlabels.php#bannerafternumber) of a waypoint label should generally match the route+banner of an intersecting route.
Beyond that, abbrevs (https://travelmapping.net/devel/manual/wayptlabels.php#abbrev) are generally only needed to disambiguate; say, if a given file refers to more than one flavor of N121 or of N192Byp,etc.
I haven't been following closely enough to know whether "Old" should be added as a banner to the system CSVs, or removed from the waypoint labels. Same for that one "Spr" on the list.
Long labels like N299BypHan/N463BypTok:
Not wrong per se but the manual suggests avoiding them:
If one of the two highways is already long as a label (e.g., a bannered route like US42BusKin), consider skipping the city abbrev. or even skipping the whole second route.
So for N17BypSom/N17BypAge, if that were to otherwise become N17Byp/N17Byp, that might be a good candidate for "skipping the whole second route".
N299BypHan/N463BypTok OTOH could be shortened to N299Byp/N463Byp -- or another option that the manual is quiet on but that people have been doing for years is to just list the banner once, implying that it applies to both route numbers: N299/N463Byp.
-
With the promotion of jpnhks (Kansai) to preview last night, all Japanese national highways are now at preview level.
459 highways
1200 entries
30000 miles
Next few tasks include:
1) Remove all the Old and Spr abbreviations from waypoint and file names.
2) Make a second pass through the roads, in numeric sequence, to make sure I was consistent in waypoint selection and naming.
3) Now that I can see all the routes on one map, I can better determine if I need to remove or add shaping points. (The road network is rather dense on Honshu so I tended to use more shaping points there.)
I have had the highways colored red so that color-blind me could easily see them during development. What color should I change this to? Salmon?
-
You should use the same color what's used for other national highway systems in Asia.
You could also go ahead now and:
Once all individual systems are complete, you can merge the systems into one again.
-
There are 564 pairs (https://travelmapping.net/logs/nmpbyregion/) of near-miss-points (https://travelmapping.net/devel/manual/syserr.php#nearmisspoint) to be checked if the wp coords need be synched (I had a quick look into it, and all I checked need to be synced) or marked FP: https://courses.teresco.org/metal/hdx/?load=jpn.nmp
I recommend synching the coords now but only mark the FPs on activation.
-
Regarding keeping intersection points aligned, I know everyone has their own methods. When I used to draft highway systems for CHM and during the early days of TM, I would always start the drafting of a new route by bringing in all of the points from existing routes that intersect (grep is your friend), line those up, then fill in the other needed points in the WPT editor. I found that it saved time while drafting and prevented nearly all non-FP NMPs.
-
Japan's datacheck errors can be seen at https://travelmapping.net/devel/datacheck.php?rg=JPN
VISIBLE_DISTANCE (https://travelmapping.net/devel/datacheck.php?rg=JPN&show=VISIBLE_DISTANCE) cases are handled a bit differently...
These are often false positives, and aren't reported once the relevant systems are promoted to active. So there's no need to mark them FP; just add intermediate points to fix the ones you can.
It may help to filter them out (https://travelmapping.net/devel/datacheck.php?rg=JPN&hide=VISIBLE_DISTANCE), address the other errors first, and then come back to these last.
N57BypKit needs a couple shaping points. Recommend:
N57 http://www.openstreetmap.org/?lat=32.921039&lon=131.000077
+X840372 http://www.openstreetmap.org/?lat=32.924118&lon=130.987541
P23 http://www.openstreetmap.org/?lat=32.915810&lon=130.981731
OtsHig http://www.openstreetmap.org/?lat=32.899815&lon=130.929381
+X767139 http://www.openstreetmap.org/?lat=32.896153&lon=130.896277
P339 http://www.openstreetmap.org/?lat=32.887664&lon=130.896727
-
It may help to filter them out (https://travelmapping.net/devel/datacheck.php?rg=JPN&hide=VISIBLE_DISTANCE), address the other errors first, and then come back to these last.
The errors highlighted in red are more important, especially Duplicate_Label (https://travelmapping.net/devel/manual/syserr.php#DUPLICATE_LABEL). Hidden_Junction (https://travelmapping.net/devel/manual/syserr.php#HIDDEN_JUNCTION) are usually in combination with NMPs. Dealing with NMPs (on HDX) is likely easier than trying to find the error with HB (opened with datacheck link).
-
Thanks for all the suggestions. I'm currently in the puckerbrush in rural Maine and have intermittent web access. I'll be home tomorrow and can start working on these issues then.
FYI all Japan national highways are now in jpnh. The system files for the temporary systems should be deleted by today's submission. I needed to use Github Desktop to do the bulk moves. Have you found it useful for other tasks?
-
I needed to use Github Desktop to do the bulk moves. Have you found it useful for other tasks?
I always use Github Desktop because I always open all (sometimes up to 1,000) relevant files to pick up wp coords to avoid NMPs.
-
Not sure if you're aware or if they might be of any use, but there are .wpt files generated by each site update that line up all NMPs. Unfortunately that would include (unmarked only? I'd have to check) FPs. They can be found on the server in /home/www/tm/nmp_merged or on the web under https://travelmapping.net/nmp_merged/
-
All the data errors and NMPs for Japan systems have been fixed or marked as FPs. I also have done a first pass at checking concurrencies.
I just uploaded an SVG file for the jpnh system. I have a few questions about how the shields directory is used.
-- How do these SVG files get chosen for use? Is it based on the file name, in this case template_jpnh.svg.
-- How can I add another font? The svg file should probably be using IPAGothic, a free Japanese sans-serif font.
-- The roads in the jpntk system have separate shields for each city network. I did see shields unique to one road, but is it possible to have a shield shared by some but not all of a system?
-- The jpne system could use a simple shared shield, or for each expressway have much more complicated separate shields that list the road name. Which would be the better choice?
Because of their shape, national highway shields are known colloquially as onigiri - meaning rice ball.
-
I just uploaded an SVG file for the jpnh system. I have a few questions about how the shields directory is used.
-- How do these SVG files get chosen for use? Is it based on the file name, in this case template_jpnh.svg.
Thanks :) If memory serves*, you need to call the svg file from https://github.com/TravelMapping/Web/blob/master/shields/shieldgen.php
@the-spui-ninja (or @rschen7754?) might help you if you need support.
*I dealt with it in 2016/17 but don't remember details. I think that the code was reworked meanwhile?!?
-
No, it is loaded automatically (https://github.com/TravelMapping/Web/blob/master/shields/shieldgen.php#L46) but most shields require a special treatment (https://github.com/TravelMapping/Web/blob/master/shields/shieldgen.php#L55).
-
I looked at shieldgen.php and it looks pretty easy to add a case for jpnh. All I need to do is strip out the N prefix.
case 'jpnh':
$routeNum = str_replace("N", "", $row['route']);
$svg = str_replace("***NUMBER***", $routeNum, $svg);
break;
I'm leery of adding it to the code for
case 'alakt':
case 'alavt':
case 'canmbw': .....
because I don't know if any of those cases have an N in prefixes.
Looking at shieldgen answered my question about the jpntk system having separate shields for each city network. It should be possible by adding a separate case for jpntk that determines the city network being processed.
-
Thanks for working on the Japan shields. Instead of pulling into the master branch of the repository, I've pulled your work so far into a branch named jpnshields. I've installed what's there on tmdevel, for example:
https://tmdevel.teresco.org/hb/showroute.php?units=miles&u=terescoj&r=jpn.n002
It looks like we're on the right track, but something's not quite right.
I might be able to take a look a little later today, but please feel free to investigate and submit another PR (to that branch, if you can) and I can put it on tmdevel to try it out.
-
The shields don't appear on https://tmdevel.teresco.org/shields/clinched.php?units=miles&u=nagamasa&cort=traveled (I've selected a traveler with jpnh travels)
chlinched.php might help to see more shields at the same time to validate if changes work.
I never had to do anything to make the shields visible there.
-
@nezinscot if you'd like to be able to experiment and are comfortable with working your way around the Unix command line and transferring files, I can set up a development server where you can try things out. Send me a direct message here or email me if you'd like to go in that direction.
-
Maybe starting in mid-July I can work with the development server.
Monday I'm heading to central Texas for two weeks. (My sister owes me bigtime for trading coastal Maine summer weather for Texas 100+ heat.)
-
The shields for jpnh is now displaying correctly working on the development server. The svg needed a viewport to be set.
The shield for jpne is also now available on the development server. Both shields are displaying on the clinched/traveled roads page
-
I'll merge those into the mainline and install on the production server if it's all looking good to go.
-
It looks good enough for now. I vote to promote it.
I eventually should tweak the font size, position, and possibly the kerning of the number text. That would be much easier on a development server because it'll require many iterations to get right.
-
The shields are now on the main site. Thanks!
-
Thank you! Work on the front end is always welcome :)
I've closed the Github issue for the jpne shield (https://github.com/TravelMapping/Web/issues/682).
-
hwy_data/JPN/jpntk/jpn.hie5.wpt is unprocessed (https://travelmapping.net/logs/unprocessedwpts.log). Please check if the route should be added to csv files or if the wpt file should be deleted.
-
hwy_data/JPN/jpntk/jpn.hie5.wpt is unprocessed (https://travelmapping.net/logs/unprocessedwpts.log). Add the route to csv files or delete the wpt file.
Why? What harm does its unprocessed existence do?
The route is under construction, and the file consists of the jpntk.csv entry, and an intersecting point, to make things easier for me when it opens. It's now not me who'll be dealing with it when it opens, and I'm not saying keep it, but nezinscot shouldn't have to delete it just because it appears in a log.
-
Thanks and sorrY! Text changed and
striked through since irrelevant now.
I thought that it might be unprocessed by accident.........
-
I have begun a second pass through the Japanese national highways, starting with the N300-N325 group.
As a result of the second pass, and doing recent updates because of new road openings, I've decided that I should change the way I designate the main road. Before, when there was a choice I followed the oldest existing route, typically the route through a congested urban area. The other option I designated as a bypass. I now believe I should put the main road on the through route, which is almost always the bypass.
Additionally I am removing the Byp designation from routes. There is no official designation marking a route as a Bypass, and routes are not signed as Bypass. I formerly based Byp on the route location and function. (An added complication is that almost all new road segments have their own unique name that contains Bypass, so everything new is a bypass in some way. Ambiguity is the norm in Japan and in Japanese.)
I now plan to use this route naming scheme:
1) The main road is the through road when there is a choice. The route name is Nxxx.
2) All other routes with the same number have an appended location abbreviation - e.g. N300Yam, N300Mat
3) No routes will use Byp in jpnh.cvs.
Some expressways are also designated as "motorway on general national highway". I will treat the concurrent national highway designation the same as any other route and not mark them as Byp.
-
I now plan to use this route naming scheme:
1) The main road is the through road when there is a choice. The route name is Nxxx.
2) All other routes with the same number have an appended location abbreviation - e.g. N300Yam, N300Mat
3) No routes will use Byp in jpnh.cvs.
Seconded!
-
- E9 (Nagato) wps do not match the N route wp coords
- N305/N365 concurrency is broken
I guess that the remaining NMPs might be intended: https://courses.teresco.org/metal/hdx/?load=jpn.nmp