Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[tckma]

If you're interested, what technical expertise do you have, which parts of the project are you interested in contributing to, and how often do you expect to have time available?

Primarily C/C++, and bash and Python shell scripting in Unix environments.  I am passable in Java but it takes me longer to get things done in that language than more seasoned Java people.  I don't do a lot of UI -- mostly back-end and mid-level stuff.  I do have some database experience but I tend to defer to more expert DB folks when I need to.

The states I'm probably most knowledgeable about are all the New England states, NY, MD, and northern VA.  I'm less familiar with the rest of VA, NC, DE, and NJ but have more experience driving and navigating in those states than in others.  If any of you are familiar with Waze, I'm an Area Manager in north-central Maryland and I also try to participate in MapRaids.

My schedule is going to vary widely depending on my workload at work and my volunteer commitments.  I tend to work on road stuff when it's a slow workday or (as today) our VPN/Firewall is down.

[Sub-Urbanite]

I'd like to keep Utah, and would be fine "holding" Nevada and Arizona. Could assist with other western states as well.

[sipes23]

It looks like I'll be moving to Wyoming by the end of the summer. I can't claim to be an expert on the roads there, but I'll probably have a better handle on the situation there than some other folks. As always, I've got no programming chops, but I can do data entry.

[Jim]

Now that we have more of a start on some building blocks for the new travel mapping system, I think it's time to start coordinating some activities so we can make the best progress as a group.  I'll continue to have a little time for a few more weeks, then my time will become much more limited first by some travel and then it will be time to ramp up preparation for teaching in the fall.

It looks like the majority of volunteers are on the highway data side of things, which we'll need, but I don't think we're quite there yet.  I think we need to make a priority out of moving data to our new format, and having the support tools in place to draft new and update existing routes, including a highway data editor and error checks for the data.  Also need to report possible errors and have a way to record the known false positives.  We should also agree on and write out our new version of the rules to maintain good data quality (waypoint naming, spacing, which routes get included in which kinds of systems, etc.) and to come up with a way to allow many people to contribute and maintain quality through peer review.

I'm happy to take on a good amount of the responsibility for core data processing but I expect there are some others who will be better suited to manage the rules and the actual data.  It makes sense to me for some of the core data contributors from CHM to take that lead.

[oscar]

If it can wait until late July, when my major summer travels will be done, I can take on creation of an instruction manual for creation of new route files and route systems. That could ease the process of "learning the ropes" by new contributors, and put more of the process in writing to make it less necessary for them to ask for help.

We could use this to tweak the old CHM instructions. Some issues that come to mind include breaking up routes at short ferry crossings, locally-maintained segments of state/province/etc.-designated routes, and treatment of unsigned routes (or unsigned segments of otherwise signed routes). Any changes I would propose would be open to discussion, here or in a separate new Travel Mapping forum. Other suggestions, for things to change where the old instructions or other rules caused heartburn, would be welcome.

[rickmastfan67]

I think we need to make a priority out of moving data to our new format, and having the support tools in place to draft new and update existing routes, including a highway data editor and error checks for the data.  Also need to report possible errors and have a way to record the known false positives.

When we get to the 'FP' part, hopefully we can have a check for intersections that are XXX off from each other when they shouldn't be (like in PA the US-40/I-79 interchange because it has different coordinates for each route when it shouldn't) so we can fix that when necessary and then mark the rest as 'FP' when that's needed because of trying to avoid false multiplexes.

[yakra]

I agree with James and Si; I'd like to see Near-Miss Points flagged too.

WRT rules/guidelines/HowTo, why not just start off with the existing Manual Tim wrote, and look into any additions/clarifications that
may be needed there, and any heartburn related changes too. (One that bugged me that I was ultimately too tired to fight back on was 3-letter county suffixes for county roads; I think they should be allowed. (Yeah, after making (Jeff, was it?) go thru all that trouble changing them...  ))

[oscar]

WRT rules/guidelines/HowTo, why not just start off with the existing Manual Tim wrote, and look into any additions/clarifications that may be needed there, and any heartburn related changes too. (One that bugged me that I was ultimately too tired to fight back on was 3-letter county suffixes for county roads; I think they should be allowed. (Yeah, after making (Jeff, was it?) go thru all that trouble changing them...  ))

My plan was to start with the existing manual, and try to improve it. 

One improvement I'd make, as a practical pointer to new team members, is to strongly suggest starting new route files by stealing as many points as possible from existing routes, to make sure they synch up; then set the points for intersections with other routes in the new route set, so those points can be swiped for those other routes' files. 

We can set up a separate thread on this topic, once I get to work on this.

[Highway63]

(One that bugged me that I was ultimately too tired to fight back on was 3-letter county suffixes for county roads; I think they should be allowed. (Yeah, after making (Jeff, was it?) go thru all that trouble changing them...  ))

Yes, I was the one who was going to suffer for that. However, it appears/I hope my procrastination paid off! (Never did it.) I'd like to keep the Wisconsin and Missouri naming conventions I have.

[froggie]

Not just you, but me too...though since I all but dropped CHM at the time between deployments and Tim's obstinance on Vermont, he wound up doing the work for Minnesota.

[rickmastfan67]

Florida partially had this problem as well when I occasionally ran across duplicate CR's with the same number.  A lot easier to be able to use the 3 letter County abbreviation when needed (since the county name is on the shield!!) instead of finding a city name near by or '_A'.

[yakra]

While I think the three letter county abbreviation idea had some merit, it never quite cut it for me. I'm looking at Kansas and Nebraska here, with their patchwork of A/B/C/1/2/3 Rd/St/Ave, Rd/St/Ave 1/2/3/A/B/C, both cardinal & ordinal numbers, Arrowhead/Brown/Comanche Rd, and every other conceivable combination. This never seemed all that adaptable to the (prefixed) abbreviation approach; in my mind its asking to be treated like any other ordinary local road name. Thus making the _suffixes useful.

[froggie]

When I initially created the Minnesota lists (because guidance wasn't clear at that point), I worked out a "gentleman's agreement" with Tim whereby if the point was within a town or village, I used the name of the town or village, otherwise I used the county name.  My only potential conflict would've been with MN 28 (Stevens and Stearns Counties), but I don't believe it was an issue.