Mapping Standards (new posts)

"White Trails" Images: Re: "White Trails" Images

Mon, 28 Jan 2008 15:40:47 +0000

It's fine to do them later, as we get around to it.

pseudo trail maps? … doesn't matter to me what they're called, we can always change it later.
I imagine we'll come up with other characteristics than white trails that are needed to make the maps look good, so the name just needs to reflect that we're trying to mimic the look of published maps.

I'm thinking that glades should just be outlined in white, otherwise they dominate the look of the map.

"White Trails" Images: "White Trails" Images

Thu, 17 Jan 2008 04:17:33 +0000

We need to decide what we want to do about them. I like them alot, but they seem rather complicated to explain the creation of in the standards page and the submissions page. I could write up an explanation, but we don't want to make it too complicated for people to submit maps. My current opinion would be for us to go through submitted maps and add the "white trails" image later, but that might be a lot of work. Opinons?

we also need to decide on what we're going to call these pictures.

suggestions for future standards: Re: suggestions for future standards

Wed, 16 Jan 2008 16:19:48 +0000

1. good point about color. I think the midstation thing is good for a person viewing it (might want to specify a marker size and color so no one gets gaudy), but it will probably be easier for the software to recognize an intermediate point in the lift path. So I think we should leave the recommendation for an intermediate point in the standards.
5. yeah, we need to refresh those images, but it's not too pressing—I am going to concentrate on software since I'm on a roll. I enjoy the mapping and will keep doing that during breaks in the software "work." Do you think the white boundaries version might be good to use as our screen capture on each area page, or stick with the non-obscured version?

suggestions for future standards: Re: suggestions for future standards

Tue, 15 Jan 2008 22:20:21 +0000

1. I'm gonna figure out the color in a minute, and I'll add that to the wiki. I just added a section on mid-stations, and I'll post the folder organization when i do the terrain park coloring. As far as keeping them seperate, we're already planning on having the software differentiate difficulties based on color, so why not use the same thing for terrain park?
5. gotcha. Should we try and add the white trails image to all of the page? maybe under a new heading?

suggestions for future standards: Re: suggestions for future standards

Tue, 15 Jan 2008 22:03:37 +0000

1. Want to pick a color? Suggestion for how they should be kept separately?
2. Will do in the future. I'll try to remember to add this to the standards wiki.
3. I figured so—it's almost duplicates the trail map link but has date as well.
4. Ok, 1.1 works for me.
5. If you want to make all the trail boundaries filled, you can right click on the "Trail Boundaries" folder and go to "Properties." However, when you try to change the to "Filled," it will first ask you to link the properties of all items in the folder. If you want to keep the trail boundary colors different, you can't do this and the only way forward is to open each trail boundary individually and set it to "filled." Did I explain that well enough?
6. Ok.

suggestions for future standards: Re: suggestions for future standards

Mon, 14 Jan 2008 14:08:45 +0000

1. I think an orange color works best. We'll separate the terrain park trails so that they don't mess up stats with pitch, etc.
2. We should ignore tubing lifts if not used by skiers. I've never seen tubing terrain used for skiing, anyway.
3. Given the viewing problems, removing the info from GE makes sense. Let's keep it in the wiki. I'll add a field to the area page template.
4. Sounds good to me. I think that we should decide on the terrain park color and add that, plus the new folder org. and make that version 1.1
5. I'm not quite sure what you mean by linking the trail boundaries' properties.
6. We have a 300mb limit for uploads. I don't think there are any bandwidth issues. The wikidot site says that they can give you more storage if you need it. Right now we're using 27.0 megs.

suggestions for future standards: Re: suggestions for future standards

Mon, 14 Jan 2008 03:25:05 +0000

Some thoughts:
1. Need to figure out how to handle freestyle/terrain park/half pipes. There are a lot more of these than I realized, and many are getting orange(?) ratings or being rated at really high difficulties even though the pitch is low. These will mess up our stats.
2. Need to figure out how to handle tubing. Maybe we could ignore it other than lifts that are also used for skiers? Is the terrain ever used for skiing as well?
3. I've been putting source information in the "description" pane of each area in GE. Now that I have a lot of them, the fact that GE displays the first couple lines of this info in the "places" browser on the left has become annoying. I can only see 1/3 the number of areas I would be able to see at once if they had nothing in the description. Should I remove this info and just keep it on the wiki?
4. Having trail boundaries separate is working well, but we then need to name this other folder. I think it might be best to rename "Trails" to "Trail Centerlines" and call the new folder "Trail Boundaries" so it mirrors the name of our mapping standards headings. I jumped the gun and did this on my recent areas, so they are technically non-compliant. If we do this, should it be v1.0 or 1.1?
5. I'm questioning whether we need to bother giving trail boundaries edge colors. As long as there is a 1-to-1 mapping between boundaries and centerlines, the software could look up the centerline to get the difficulty, and that would save us a lot of work. It also makes it possible to link the trail boundaries' properties so that you can easily turn on white fill to produce nice screen captures. The only issue I see are trails that have sections with different ratings. To figure out which boundary corresponds to which trail, the software would have to do some (fairly simple) math.
6. I've been using PNG's for the ski area screen shots to avoid the fuzzy effect of JPG. I see they are a lot bigger than I expected, though—do we have size/bandwidth limits to worry about? Should we switch to JPG anyway? Wikidot doesn't create a thumbnail when you shrink a picture, so they're even taking a long time to display.

suggestions for future standards: Re: suggestions for future standards

Thu, 10 Jan 2008 15:49:11 +0000

hmm. I think that for a resort the size of Sunday River or Killington, having subfolders for peaks makes sense. Having 131 or 200 trails in one trails folder would be a major pain. I think that lifts should remain on one folder which can be turned on and off all at once.

Mapping centerlines and boundaries in seperate folders would also be a pain, but ultimately would be a good idea, i think. I don't think that anythiing other than trails and lifts should be in the kmz. Maybe noted on the area page, but not downloadable with the kmz.

suggestions for future standards: suggestions for future standards

Thu, 10 Jan 2008 15:28:14 +0000

I think we should further define how subfolders can be used to better organize areas. For example, on the Sunday River map I tried to break down the area into separate peaks. This can make it more difficult to find a trail you're looking for (especially for ones that are not clearly associated with one peak), but without it the trail list can become unwieldy. If this is permitted, should lifts be separated by peak as well?

Another case where I think subfolder organization might help is in managing trail boundaries vs. centerlines. When I want to turn trail boundaries on/off, I usually want to do it for all trails at once, and since they are not in a separate folder from the trail centerlines, which I usually leave on, it is a very tedious process. Is this view shared by others?

I think it goes without saying that planned expansions should be in a separate folder so they can be turned on/off with one click.

We also should consider whether/what kind of points of interest (lodges, bars, tourist attractions) should be allowed in the kmz files.

colors: Re: colors

Wed, 09 Jan 2008 04:52:52 +0000

when you download my maps, what do the colors look like? This is a serious problem that we're gonna need a solution to pretty quickly. It's the only thing holding us back from releasing Standards Version 1.0, in my opinion.

colors: Re: colors

Tue, 08 Jan 2008 22:16:31 +0000

Looks like we have very different monitors—that blue looks almost gray on my machine. Would printers be more consistent in representing colors? Another approach would be to use the meter on an actual trail sign at a major ski area that has probably put some thought into their signs, such as a former ASC resort…?

colors: Re: colors

Sun, 06 Jan 2008 05:42:59 +0000

the colors on this page:

http://skiing.about.com/od/safetyforskiers/a/skitrailratings.htm

look good to me. I vote for those. my digital color meter reports RGB values of (0,153,0) for green, (16,109,179) for blue, and obviously (0,0,0) for black.

Standards Version: Standards Version

Sun, 06 Jan 2008 05:27:43 +0000

Considering that we are currently mapping and posting areas without a set-in-stone document to define out standards, I propose that we create a GEOSAP Standards 1.0 which will be the goal of our work on the standards page. When that page is done, we will post it as GEOSAP Standards 1.0. Any changes to the standards will be reflected in a revision page. When a map is posted, it should be marked as to what standards version it applies to. All work done now should be marked as GEOSAP Standards 0 to reflect the lack of a concrete standard which was followed.

colors: colors

Thu, 03 Jan 2008 03:16:24 +0000

This seems like an independent, if not official, source for which green/blue we should use:
http://skiing.about.com/od/safetyforskiers/a/skitrailratings.htm
(click the green square then click "next" within the popup to see the blue square)

… it's pretty close to another site I found:
http://www.alpinemtsp.org/Ski_Safety.htm#How_Trails_Are_Rated

Trying to mimic the first one, I find RGB values of 0,150,0 gets close to the green, and 50,110,200 gets close to the blue. The black is obviously going to be 0,0,0.

Please provide opinions—once we make this decision it will be a *lot* of work to change.

What info should be on the state pages?: Re: What info should be on the state pages?

Tue, 01 Jan 2008 22:43:29 +0000

Have you tried wiki tables, and do you think they would work for the state pages?
The columns could be categories matching those on our standards page, and we could put numerical ratings or codes in each column to indicate how well developed each feature is.

File organization: Re: File organization

Mon, 31 Dec 2007 18:02:13 +0000

Initials have been added. I'm not sure why I assumed it was going to automatically zoom to encompass new areas… duh.

File organization: Re: File organization

Mon, 31 Dec 2007 16:42:21 +0000

The map did update, you just have to scroll out to see all of the places. Every once in a while we'll have to update the actual code to make sure that the default view shows all of the areas. good work!

One thing i would recommend is putting the state initials after area.

What info should be on the state pages?: Re: What info should be on the state pages?

Mon, 31 Dec 2007 16:40:55 +0000

we should keep the stats off the pages until we can produce our own data for a comparison. As you said, one less thing to update.

What info should be on the state pages?: Re: What info should be on the state pages?

Mon, 31 Dec 2007 13:26:13 +0000

It looks like you got rid of the stats—I agree with your reasoning above, so should we re-add them, or do you just want to store them in a different place?

File organization: Re: File organization

Mon, 31 Dec 2007 13:00:43 +0000

Ok, I updated the map (we'll definitely want to get an automatic export from Google Earth working soon, since it's pretty hard to find places without being able to search or see place names). It didn't update on the GEOSAP start page, though…?