Things to do (CHM)

[english si]

In no particular order, and I'm just spitballing here. Meant as a talking point.

1) Software stuff
- create map generator
- create highway browser
- create stats pages
- create tools (wpt editor, concurrency check, labels in use,
- create forum
- create .css / site design
- create home page and other static pages (manual, sources, etc)
- create site-wide log in system
- create .list file uploader (for all users)
- create highway data update system (for collaborators only)
- create process that redraws the maps and updates the stats (automatically running daily?, biweekly?, weekly?)
- update highway data so up-to-date
- finish peer review of systems in that process

2) Hardware stuff
- get server
- upload stuff to server

3) People stuff
- contact existing and past collaborators
- contact existing users of the site
- sort out how the project is going to work

4) Moving beyond the basics
- new systems
- new collaborators
- better borders in Eurasiafrica
- .list file creator

[oscar]

4) Moving beyond the basics
- new systems
- new collaborators
- better borders in Eurasiafrica
- .list file creator

Expanding on the borders point, re-doing water boundaries, so user maps don't show a lot of highways offshore (as is especially noticeable in New York City user maps).  The way CHM did it, tweaking water boundaries was an incredible pain, with lots of processing time needed to redraw the ocean, and so was strongly discouraged.  AFAIK, last time we went through that exercise was when we had to dredge up two additional islands from the bottom of the Pacific, for the Hawaii State Highways route set. 

Land borders could be improved in some places in North America, particularly for the Arctic jurisdictions.  But fortunately not a moving target as with the Eastern Hemisphere.

Is there much interest in expanding geographic coverage of the project into Asia (except for the former Soviet Union and Turkey, which CHM covers), or Africa or South America?  I think this can wait awhile, along with any land and water boundaries re-drawing there.

[oscar]

5)  Find a way to keep jokers out of this sub-forum, so it can stay more or less on-topic.

[Zeffy]

5)  Find a way to keep jokers out of this sub-forum, so it can stay more or less on-topic.

Sorry about that, I'll lend my time in either moving or deleting posts that don't pertain to the project.

As to everyone else, all forum rules remain in effect for this section. The same penalties will apply to those who break the rules in this section just like the other ones.

[Bickendan]

4) Moving beyond the basics
- new systems
- new collaborators
- better borders in Eurasiafrica
- .list file creator

Expanding on the borders point, re-doing water boundaries, so user maps don't show a lot of highways offshore (as is especially noticeable in New York City user maps).  The way CHM did it, tweaking water boundaries was an incredible pain, with lots of processing time needed to redraw the ocean, and so was strongly discouraged.  AFAIK, last time we went through that exercise was when we had to dredge up two additional islands from the bottom of the Pacific, for the Hawaii State Highways route set. 

Land borders could be improved in some places in North America, particularly for the Arctic jurisdictions.  But fortunately not a moving target as with the Eastern Hemisphere.

Is there much interest in expanding geographic coverage of the project into Asia (except for the former Soviet Union and Turkey, which CHM covers), or Africa or South America?  I think this can wait awhile, along with any land and water boundaries re-drawing there.

While possibly not Asia or Africa, we probably do want to add Australia (and to an extent, New Zealand?).

[hotdogPi]

What about the possibility of being able to update the routes you have been on while logged in, without requiring emailing a certain person/bot in order to update it?

[Scott5114]

Sorry, Tapatalk doesn't make subforums obvious and it's thus very rare that I have any idea what section a post is in.  Regardless, my obliquely made point was the point of the thread was and is completely lost on me.  Carry on.

(To be honest, my misunderstanding of this thread as being "What is on your to-do list?" struck me as no more nonsensical a topic than "What popular items does a store not carry?" and the like.)

On the Android Tapatalk, at least, if you touch the "AARoads" name in the upper left, it will give you a dropdown of all the subforums.

[froggie]

What about the possibility of being able to update the routes you have been on while logged in, without requiring emailing a certain person/bot in order to update it?

Listed under #4, .list file creator.

[vdeane]

While possibly not Asia or Africa, we probably do want to add Australia (and to an extent, New Zealand?).

New Zealand is a country I thought would be nice to have on, even if I never actually make it out there.  Adding the Mexican federal routes some day would probably be a good idea as well.

[Thing 342]

Starting some sort of initial repository for the data should probably be at the very top of the list, just so that the folks developing the systems have some test data to work with. A lot of people have suggested GitHub for this sort of thing.

[english si]

(To be honest, my misunderstanding of this thread as being "What is on your to-do list?" struck me as no more nonsensical a topic than "What popular items does a store not carry?" and the like.)

I've renamed the thread. I forgot tapatalk doesn't provide context.

As for Eurasiafrica (and Oceania and South America too) borders, obviously as and when - rather than meticulous boundaries for places the project doesn't care about. I see no reason to, if someone is willing to put in the work, we can't expand there. I've got some stuff done.

[1995hoo]

Tapatalk can provide context depending on which version you use. The tablet version (which I sometimes, but not always, use on my iPad) displays the subforum underneath the sample post except in the manner of a Twitter handle (for example, it might say "@Political Talk" on a board that has such).

[Chris]

I did the Netherlands and Switzerland systems back in 2010, when I was temporarily unemployed.

Unfortunately I currently don't have the time to start another project.

To keep up with new freeway openings, the motorway openings around the world thread on Skyscrapercity may be of help. We try to log all freeway-type openings worldwide, it currently has over a thousand entries in just over 3 years.

[Thing 342]

Here's a very early proof-of-concept highway browser that I've been working on: http://www.thing342.us/highwayBrowser.html

[english si]

^^ Other than the lack of map, etc, I quite like.

[Bickendan]

How much trace fidelity are we looking to have for 2.0? Do we want to continue using 1.0's rough trace or do we want to tighten up for better mileage accuracy?

[oscar]

How much trace fidelity are we looking to have for 2.0? Do we want to continue using 1.0's rough trace or do we want to tighten up for better mileage accuracy?

More trace fidelity, and accurate distance estimates, means more shaping points to clog up the server. I was surprised that I was able to trace the curvaceous H! 360 (Maui's Hana Highway, with over 600 hairpin curves in less than 35 miles), using 1.0 standards, with less than two dozen shaping and other points. That threw distance accuracy off by about 25%, but improving that might require hundreds of extra shaping points just for that one route.

[Bickendan]

I looked at HI 360 and it reminded me of CA 1. That wasn't a fun route to draft.
CA 18's first draft was also pretty nasty.

[wphiii]

Here's a very early proof-of-concept highway browser that I've been working on: http://www.thing342.us/highwayBrowser.html

Looks very promising, but a minor nit (and maybe I'm in the minority): I will say I liked being able to pick a state and have everything in that state listed all at once, whereas the way your drop-downs work seems like you're forced to choose the highway classification first.

[Thing 342]

^^ Other than the lack of map, etc, I quite like.

The OpenLayers API has pissed me off a great deal, so I've been holding back on adding a map.

[Jim]

How much trace fidelity are we looking to have for 2.0? Do we want to continue using 1.0's rough trace or do we want to tighten up for better mileage accuracy?

I'd like to wait to see how much computational power this will take before going for finer-grained traces.  Initially, I think it makes sense to stick with the CHM project's naming guidelines and point densities.

[rickmastfan67]

How much trace fidelity are we looking to have for 2.0? Do we want to continue using 1.0's rough trace or do we want to tighten up for better mileage accuracy?

I'd like to wait to see how much computational power this will take before going for finer-grained traces.  Initially, I think it makes sense to stick with the CHM project's naming guidelines and point densities.

I agree with Jim.  We don't want to go overkill, at least at the start.  About the only changes to the current scheme in making the files is the addition of exit numbers on US Highways (excluding where just exit "#'s" are 'A' & 'B') is what I'd agree with.  We'd just have to figure out how to deal with states where the exit numbers are duplicated (I know I remember hearing that happens at least in one state).

[bulldog1979]

How much trace fidelity are we looking to have for 2.0? Do we want to continue using 1.0's rough trace or do we want to tighten up for better mileage accuracy?

I'd like to wait to see how much computational power this will take before going for finer-grained traces.  Initially, I think it makes sense to stick with the CHM project's naming guidelines and point densities.

I agree with Jim.  We don't want to go overkill, at least at the start.  About the only changes to the current scheme in making the files is the addition of exit numbers on US Highways (excluding where just exit "#'s" are 'A' & 'B') is what I'd agree with.  We'd just have to figure out how to deal with states where the exit numbers are duplicated (I know I remember hearing that happens at least in one state).

US 127 has two exit numbered 139: the southern end of Bus US 127 for Mount Pleasant based on US 127's mile markers, and M-106 by Jackson using I-94's mile markers.

[rickmastfan67]

How much trace fidelity are we looking to have for 2.0? Do we want to continue using 1.0's rough trace or do we want to tighten up for better mileage accuracy?

I'd like to wait to see how much computational power this will take before going for finer-grained traces.  Initially, I think it makes sense to stick with the CHM project's naming guidelines and point densities.

I agree with Jim.  We don't want to go overkill, at least at the start.  About the only changes to the current scheme in making the files is the addition of exit numbers on US Highways (excluding where just exit "#'s" are 'A' & 'B') is what I'd agree with.  We'd just have to figure out how to deal with states where the exit numbers are duplicated (I know I remember hearing that happens at least in one state).

US 127 has two exit numbered 139: the southern end of Bus US 127 for Mount Pleasant based on US 127's mile markers, and M-106 by Jackson using I-94's mile markers.

That one wouldn't be a problem.  We have always had exit numbers along Interstates for US Highways.  The I-94 one on US-127 would still be tagged as 'I-94(139)', while the 'converted' one from a road label on the US-127 only segment would be '139'.

The problem we would have to deal with is the states that give exit number to bypasses, but reset them on each bypass.

[froggie]

The problem we would have to deal with is the states that give exit number to bypasses, but reset them on each bypass.

Easiest way to do this is to leave things as-is and skip adding exit numbers in such cases.