Discussions on Physical Geography
Start a New Discussion
-
-
When typing mountain ranges, i come across "Escarpents" quite a lot. New type?
-
These should clearly be treated differently than mountain ranges. We're starting to get a bunch of types in the Physical Geography commons that are basically buckets (types with no properties that are primarily used as a way to classify things).
I wonder if we should just have a Geological Feature type, with a property for "Type of Geological Feature" for all of these?
-
Oops. That's me above, using the wrong account.
-
'I wonder if we should just have a Geological Feature type, with a property for "Type of Geological Feature" for all of these?'
+1
-
FWIW, an escarpment is kind of a "type of mountain range" - i.e. formed by wearing away at high ground, with the ground left behind being mountain-like (that said, escarpments can also look like mesas) but I also think this could be a regional/culture-specific term - in South Africa, they refer to much of the formations around Lesotho as an escarpment, but one might argue that the easter borders of the Badlands in South Dakota is also a form of escarpment, but nobody in the US calls it that.
-
I'm not convinced that it's a type of mountain range -- most definitions describe an escarpment as being a cliff or steep slope. And I'm not entirely sure that something like the Niagara Escarpment could really be called a mountain range. (I could be wrong, mind you -- I'm just inferring from what I can find quickly online.)
-
Here's an idea: create a new type "Geographical Feature" with a property for "Type of Geographical Feature" (which would have as instances bay, escarpment, isthmus, etc.). The existing Geological Formation type could then have this as an included type. Any comments?
-
-
-
-
It seems useful to have a "Peak" type which is distinct from the geography/mountain type. All mountains have peaks, but a mountain may have well-known subsidiary peaks.
One example is the North Palisades in California:
The Wikipedia page lists three well-known subsidiary peaks (http://en.wikipedia.org/wiki/index.html?curid=4665863) and I have started to add them as distinct locations.
A geography/mountain_range often has multiple geography/mountain objects, and similarly well-known geography/mountain objects may have multiple geography/mountain_peaks (multiple subsidiary peaks and "the" peak).
Confusing the issue is that many mountains are known as peaks, whereas there are subsidiary peaks which aren't yet relegated to mountain status (since they are subsidiary and not the mountain top).
-
Good suggestion. If I understand correctly, there should be a property on Mountain called something like "Subsidiary Peaks", which would expect a new type (called, I would guess, "Subsidiary Mountain Peak") which would also be a location. Is that right?
-
Yes, that sounds like a reasonable approach!
-
I've been thinking, and I wonder if it wouldn't make more sense to simply have the type and property be for "peaks", which would make it easier to compare them or plot them on a map. E.g., if there were topics for all peaks of the North Palisades, you could easily order them by elevation; if the highest peak is considered to be the same as the Mountain topic, you have include both the mountain and its peaks in your query, which is harder. In this model, mountains with no subsidiary peaks would presumably not have any values in this property.
What do you think?
-
+1 for conflating largest and subsidiary peaks under a single type if the documentation is clear in the differences between "Mountain" and "Peak". Will the largest peak always be co-typed as a mountain or will there be a separate topic for the mountain and largest peak (likely often to have the same name)?
-
Good question. Semantically, it seems to me that the mountain and highest peak would have to be different topics (since a peak doesn't comprise subsidiary peaks and a mountain does, or can). That's my guess, anyway -- I'm not really sure what the practice in the mountaineering or geographic worlds is.
-
-
-
Hi.
In my opinion the "Shore Length" parameter is doomed to be useless, since the "actual" shore length just can't be determined. The reason is the shore's fractal nature. The Shore Length can't even be numerically approximated because with growing resolution it really runs versus infinity! See for example the exploding shore line value in Fig. 1 on this page: http://vlab.infotech.monash.edu.au/tutorials/fractals-and-scale/
Or read Mr. Mandelbrot's famous article on coast lengths: http://www.math.yale.edu/mandelbrot/web_pdfs/howLongIsTheCoastOfBritain.pdf
-
And yet, somehow, values for these impossible measurements are widely published. (-: The lake infobox on Wikipedia, whence most of our populated values come, does have a footnote stating that shore length is not a well-defined value, but a reasonable approximation is useful information, I think.
-
I understand that the availability of this kind of "information" creates the urge to include it in a semantic knowledge base. Such statistical data may help defining sophisticated queries and finding interesting patterns. But not this one.
I have several problems with shore (or coast) lengths. It starts with the fact that there is no standard measurement. One could live without one if reasonable approximations were possible. If one could say that the real value is within +-50% boundaries it could still be useful. But the problem with shore lengths is, that there is no real value.
Wikipedia states (on coasts again, but the problem is the same) that measured on satellite imagery of a given resolution the coast length of Canada differs from the CIA-Factbook value (where no information about the used resolution is given) by the factor of 10. (http://en.wikipedia.org/wiki/List_of_countries_by_length_of_coastline)
So which approximation is better? The more refined (and therefore longer) one? Well, then where to stop? 100m-resolution? 1m? The measured length will explode up to really insane values. And so even potentially interesting derived values such as Coast-to-Area ratio suffer from a huge resolution dependency. I think, since the length value alone allows no comparisons, it adds no real informational value. It's really totally useless.
-
Including a map scale property might useful here.
-
That's true.
But the problem would still lie in comparability.
Given that we want to compare two lakes covering 1km² area each. If one has 4km shore length and the other has 8km shore length, both measured in 50m-resoulution, we can say that the first one has a smoother geometry. That is really interesting since it means that the second one has a higher chance of featuring a richer flora and fauna. And many other assumptions can be made out of this comparison.
But what do 4km shore length measured in 200m-resolution mean compared with 16km in 5m-resolution? One can't tell. It could even be the same lake!
Another problem is that the used map scale most of the time simply not available. It's not published among the length values. The reason is that the problems i mentioned here are not widely known.
I'm just a fresh newbie here at freebase, but I like the Idea a lot - and even more the realization. And I think that finally this should be the place where all issues of raw data are considered and handled to form real knowledge.
-
First, welcome!
Agreed that comparability of shore lengths measured at different map scales would be difficult to impossible, but adding a map scale property would at least allow comparisons of shore lengths measured at the same scale when knowledge is available. It's a start...
You might also be interested in my MapCentral base. In particular, I've started modeling FGDC metadata with the hope that the community could start developing comprehensive metadata for maps.
-
-
-
hey, can lock be reciprocated too?
http://infrastructure.freebase.com/type/schema/base/infrastructure/lock
-
-
-
Is there a particular type I should be adding Wetland regions to?
Is Body of Water the best match?
I wished to add some of the Ramsar List of Wetlands of International Importance to Freebase.
-
It's probably better to model a "Wetland" type with a few of the general properties described on the Ramsar information sheet because not all wetlands are bodies of water. This new type would probably benefit from an explicit link to "Geographical feature", like I've done with "Focal location", especially because there are so many wetland concepts.This would give the user more opportunities for thematically characterizing the wetland.
If you want to label locations as specific Ramsar wetland types, check out my "Classification system" and "Classification code" schema. "Classification code" is also a property of "Focal location".
If you want to capture some of the more specific wetland properties used to differentiate Ramsar classes, then I suggest modeling a "Detailed wetland description" type to hold information such as floristics and soils. A longer term vision would also consider how those properties could be delegated to Ramsar and other wetland classification system schema so that locations could be classified within a user defined classification system on the fly.
-
A wetland type is definitely the way to go. If you want, I can create a basic bucket type in Physical Geography to start you off, or if you want to play around with properties, you could create your own type and have it promoted later. In terms of the Ramsar list, bear in mind that the "wetlands" on the Wikipedia list don't necessarily correspond to the ones on the actual list. (E.g., Wikipedia lists Bowling Green Bay National Park , but the official list only lists Bowling Green Bay. The park includes the bay, but also includes some mountains and probably some other dry things places.)
-
@jeff - could we have a bucket type created in Physical Geography? The 'wetland' type should include the 'location' type. I don't think we need any further properties at the moment, but can be discussed later.
@spatialed - Ramsar does have an entire classification system based around wetlands, but as a wetlands don't necessarily have to be listed by Ramsar, this classification data is best kept elsewhere e.g. in your Classification System type.
I think the 'protected site' type in the Protected Places Commons can also be used with Ramsar sites, but again a wetland doesn't necessarily have to be protected so shouldn't be included in the type.
Floral, wildlife and geological data are applicable to the majority of physical features, not just wetlands. I would suggest that a more generic 'organism habitat' type and 'geological location' type might be more appropriate than properties specifically only in the wetland type. (I'm not familiar if these exist already, or how this data is currently modelled)
-
A few notes on existing wildlife and floral schema I've created here. This is probably overkill for what you are thinking about but I've been toying with the idea of splitting some of these models apart into general and conservation components, so any suggestions for desired properties are appreciated.
I modeled a "Documented priority species" CVT to describe locations where taxa are listed as conservation priorities linked to the source of that information. It could be used for any taxa (plant or animal), with "None" listed as the priority level if the taxa is not a conservation priority. I also modeled a "Population size" CVT to describe population estimates of taxa within locations. A simpler Location/Taxa CVT could be modeled but I strongly advise explicit links to documentation whenever possible so community members can easily evaluate the accuracy and relevance of the data. Both of the CVTs mentioned above are properties of the "Focal location" type that I've been using for the purposes you describe.However, "Focal location" is very conservation focused. It could be generalized to hold ecological properties that are relevant to any location and that would be something I happy to cooperatively model with others if there is interest. Also relevant here is that awhile back I modeled an "Organism observation" to document anectdotal observations of taxa within named locations.
-
@sprocket: done: Wetland
-
-
-
A body of water can have a tunnel.
for example the Chunnel, Holland Tunnel, Lincoln Tunnel
-
Yes, but most tunnels are architectural/engineering works, rather than natural -- which is what the Physical Geography commons is mostly about. Also, tunnels don't always go under a body of water; they can also go through mountains and the like.
If you look at Holland Tunnel, you'll see it's already been typed as a Structure (architecture) and as an Engineering Project and Tunnel in sprocketonline's Engineering base.
-
Only submerged floating tunnels (of which none have ever been built) and immersed tube tunnels actually go through a body of water. All other tunnels go through the ground beneath the body of water. e.g. the Channel Tunnel (Chunnel) passes through the chalk marl stratum, clearly not a body of water.
I would use the 'adjoins' property of the location type to note that a tunnel is under a body of water, or the 'contained by' property to note that a immersed tube tunnel is in the body of water.
-
-
-
It's been suggested that the property for "date of first ascent", which is currently only visible on the topic for the mountain itself be moved to a CVT, so that first-ascenders and their dates of first ascent can be accessed from both the mountain and mountaineer topics. This would require a schema change that would potentially break any applications using this property. What do people think?
-
-
-
-
There are two wikipedia infobox lake attributes that could be loaded, but the current schema for lake is a bit questionable. Currently there are two properties:
Inflow source(s)
Outflow location
Which point to the really puzzling type "Lake in-/outflow":
I'm wondering if we could deprecate those two properties as there are only 18 instances of the combined "Lake in-/outflow".
Inflow bodies of water
Outflow body of water
Both would expect the type "Body of water".
If we make this change, I can load 1710 inflows and 1987 outflows.
-
All I can think of is that it was supposed to (somehow) connect inflows with river mouths and outflows with river sources, but failed utterly to do so. Scrapping it seems like a good idea.
-
Would you want the "body of water" type to reciprocate the properties?
-
As I look at this, this should be fairly straightforward -- all instances of "Lake in-/outflow" are also bodies of water (or should be), so we should be able to change the expected type without otherwise affecting the data.
-
OK. Go for it. Let me know when you've done it and I'll map the WP template attributes.
-
DA-497 is the bug tracking this issue.
-
It would be nice to eventually map these descriptions to FGDC metadata standards. Here is a link to the technical details of the National Hydrography Dataset for reference:
http://nhd.usgs.gov/techref.html
In particular: http://nhd.usgs.gov/chapter1/index.html
-Ed
-
-
-
I think a generalization of all basic types like mountain, lake, hill, desert, etc to something like geological formation would be helpful, particularly when adding properties to other types that can have any one of the above-mentioned types. For e.g. specifying a terrain for a sport or leisure activity or things to do-in in a tourist location etc.
-
