User talk:Vhasler: Difference between revisions
(more details on new extension usage/conversion) |
(→Now pages and data have system understandable information: new section) |
||
Line 6: | Line 6: | ||
# Change all of the pins to match the new format described on the [[ClubWiki:Using_GMaps#Pins|help page]] | # Change all of the pins to match the new format described on the [[ClubWiki:Using_GMaps#Pins|help page]] | ||
# Change the closer tag from /googlemap to /display_map | # Change the closer tag from /googlemap to /display_map | ||
== Now pages and data have system understandable information == | |||
I think I got it working, I even got the trail infobox template already populating it so no/minimal trail page changes to get it going. Another extension by the same people who did the maps extension I converted to also have an extension to allow creating "properties" and then setting information to them. Then you can do all sorts of neat things. For example, at its core the wiki now "understands" that a page is a trail and that it is 4.9 miles long (it can even automatically convert that to kilometers or whatever we want). With that "understanding" then you can do things based on that like dynamic lists, maps, computations, etc. | |||
Here's ideas based on what I've seen and thinking | |||
* Dynamic trails list - System can automatically make a trails list by specifying commands and then pull in whatever info is listed. Add a new trail, no changes to list required. The list can easily show distance from Kingsport/JC (needs to be moved to trail pages), trail length, time, etc. Probably could continue on our master trail list all parks with trails, then trails not part of a "park" - just need to craft the query for parks with trails and trails not part of a park | |||
* Dynamic trails map - similar to the list where pins are created based on trail page information | |||
* Better association of a trail within a larger park/system - On a trail page reference that it is part of park (e.g. Warriors) then on the park page you can list all trails associated with it along with info automatically pulled from the trail page like total trail length, elevation, etc. This would eliminate the need for trail name prefixes as we've done to create association (tedious to undo...) and the trails list templates for each park | |||
* Use feature above of trail association to create "hike plans" - We could create "hike plan" pages that could invoke individual trails for a plan, then sum up individual trails for total. If a trail distance is tweaked, the total plan distance updates. Then on trail pages there could be a list of plans that use that trail and park pages there could be an automatic list of hike plans within that park | |||
* Probably easily allow custom complex searching (e.g. show me all trails less than 5mi that allow dogs and not bikes and views a waterfall and is less than 25mi from Kingsport) | |||
* Automatically/dynamically calculate total trail length in the system, in a state, in a city, in a park, or in a plan | |||
* other?... | |||
You'll probably notice at the top of edit pages something about "semantic in-text annotations" - that's the new referencing system. | |||
I'm done playing for now. Still a lot of updating for the map conversion left, but since I knew I wanted to do this I wanted to get this going in case it somehow required other changes to how the maps are implemented or the page in general. It looks like "no" | |||
Infoboxes will now show an exclamation in a triangle if it doesn't understand passed data. Typically this is listing a non-number in a quantity specified property. "5-6 hours" when it wants "5". For now you still have to enter the infobox data on a trail page without units, but I plan to change that as well so it has the same default unit if you just enter a number, but if you enter "7.9 km" it will understand that and convert as necessary. |
Revision as of 09:27, 23 August 2015
Good to go on the maps conversion. See ClubWiki:Using_GMaps for the help page and recent changes for converted pages. It's a bit of a pain to convert. More tedious than anything. For some reason a search for "googlemap" doesn't return all of the pages that use the old extension. We'll just have to ferret them out over time. For now I'm just going down the trails list. --WikiSysop (talk) 21:07, 21 August 2015 (MDT)
- Still despite my best efforts searching I can't seem to search out the old extension uses to make it easier to find pages needing conversion. Conversion is a fairly straight forward process
- Remove typical opener of "googlemap version="0.9" lat="36.5700" lon="-82.2325"" and change to simply "display_map" - the new extension automatically centers and zooms on the listed pins and can zoom on a loaded kml if instructed
- Make sure the opener tag has a height definition and change/add width="auto"
- Remove any other zoom or scale and the icons definitions in the opener - usually the opener can be as simple as <display_map type="terrain" height="400" width="auto"> with the gkml definition if needed
- Change all of the pins to match the new format described on the help page
- Change the closer tag from /googlemap to /display_map
Now pages and data have system understandable information
I think I got it working, I even got the trail infobox template already populating it so no/minimal trail page changes to get it going. Another extension by the same people who did the maps extension I converted to also have an extension to allow creating "properties" and then setting information to them. Then you can do all sorts of neat things. For example, at its core the wiki now "understands" that a page is a trail and that it is 4.9 miles long (it can even automatically convert that to kilometers or whatever we want). With that "understanding" then you can do things based on that like dynamic lists, maps, computations, etc.
Here's ideas based on what I've seen and thinking
- Dynamic trails list - System can automatically make a trails list by specifying commands and then pull in whatever info is listed. Add a new trail, no changes to list required. The list can easily show distance from Kingsport/JC (needs to be moved to trail pages), trail length, time, etc. Probably could continue on our master trail list all parks with trails, then trails not part of a "park" - just need to craft the query for parks with trails and trails not part of a park
- Dynamic trails map - similar to the list where pins are created based on trail page information
- Better association of a trail within a larger park/system - On a trail page reference that it is part of park (e.g. Warriors) then on the park page you can list all trails associated with it along with info automatically pulled from the trail page like total trail length, elevation, etc. This would eliminate the need for trail name prefixes as we've done to create association (tedious to undo...) and the trails list templates for each park
- Use feature above of trail association to create "hike plans" - We could create "hike plan" pages that could invoke individual trails for a plan, then sum up individual trails for total. If a trail distance is tweaked, the total plan distance updates. Then on trail pages there could be a list of plans that use that trail and park pages there could be an automatic list of hike plans within that park
- Probably easily allow custom complex searching (e.g. show me all trails less than 5mi that allow dogs and not bikes and views a waterfall and is less than 25mi from Kingsport)
- Automatically/dynamically calculate total trail length in the system, in a state, in a city, in a park, or in a plan
- other?...
You'll probably notice at the top of edit pages something about "semantic in-text annotations" - that's the new referencing system.
I'm done playing for now. Still a lot of updating for the map conversion left, but since I knew I wanted to do this I wanted to get this going in case it somehow required other changes to how the maps are implemented or the page in general. It looks like "no"
Infoboxes will now show an exclamation in a triangle if it doesn't understand passed data. Typically this is listing a non-number in a quantity specified property. "5-6 hours" when it wants "5". For now you still have to enter the infobox data on a trail page without units, but I plan to change that as well so it has the same default unit if you just enter a number, but if you enter "7.9 km" it will understand that and convert as necessary.