Wikidata talk:WikiProject Rivers

From Wikidata
Jump to navigation Jump to search

Europe split[edit]

Should the Europe section be split into a subpage or something? -happy5214 15:58, 3 November 2012 (UTC)[reply]

Russia[edit]

Russia being a very wide place, I have created a section dedicated to the Rivers, Tributary rivers and such, that flow through or from Russia. They are very numerous once you take the tributary rivers into account.

I think we should restrain ourselves first to the main rivers only and not go into all the tributary rivers. ¤ Euterpia ¤ Talk ¤ 14:34, 23 November 2012 (UTC)[reply]

I didn't really know the english word for fleuve so I just said main river which is, I admit it, incorrect.
I meant that we should begin with the main stems which are already numerous, once those are done, we could go into the tributaries (i.e. rivers). It is less a question of "should we not put Missouri into Wikidata?" than a question of "Where should we start?". When I read the list for Russia, whith tributaries of tributaries of tributaries, I think there might be a better way to tackle this huge task.
Anyhow, I'm just going to, you know, carry on and all. ¤ Euterpia ¤ Talk ¤ 09:07, 26 November 2012 (UTC)[reply]
Moi, je parle Français a toute façon. Well, would it be fine if I just make a list of the prinsipal rivers in Europe (like in the beginning here, and the rest delegate to a subpage? This will keep the main task force relatively short, and more details will be on the subpage?--Ymblanter (talk) 11:55, 26 November 2012 (UTC)[reply]
Très bonne idée ! Keeping the task forces focused will surely help.
For Russia, I am trying to follow this article fr:Liste des cours d'eau de Russie which lists the main stems/fleuves, and some of their greatest tributaries. The table at the end of the article is particularly helpful since it can be sorted by length/longueur, débit, bassin et main river/fleuve dont la rivière est l'affluent.
The thing with the en:List of rivers in Europe is that for example, it gives the Aulne river at the same time it then lists the Daugava. Those are incomparable in size and importance... It kinda feels strange to list the Aulne as an important river we should register in Wikidata before, say, the Kamtchatka river ? ¤ Euterpia ¤ Talk ¤ 12:26, 26 November 2012 (UTC)[reply]

Property table[edit]

I've added a property table to make it easier to get a consistent dataset for rivers. Please add more properties. I'm wondering how is working in that project. Please let me know. --Werner2101 (talk) 09:48, 7 December 2014 (UTC)[reply]

Launch of WikiProject Wikidata for research[edit]

Hi, this is to let you know that we've launched WikiProject Wikidata for research in order to stimulate a closer interaction between Wikidata and research, both on a technical and a community level. As a first activity, we are drafting a research proposal on the matter (cf. blog post). It would be great if you would see room for interaction! Thanks, --Daniel Mietchen (talk) 01:48, 9 December 2014 (UTC)[reply]

Wikimania 2016[edit]

Only this week left for comments: Wikidata:Wikimania 2016 (Thank you for translating this message). --Tobias1984 (talk) 11:54, 25 November 2015 (UTC)[reply]

Hi,

Should we use coordinate location (P625) on rivers and how ? (I'd say : at least with qualifiers, but what qualifiers ?).

@Happy5214, Ymblanter, Leyo, Euterpia, Delusion23, Werner2101:

Cdlt, VIGNERON (talk) 12:10, 28 December 2015 (UTC)[reply]

Ideally, source and mouth, may be also some important points like big cities, but I do not know off-hand whether we have qualifiers available for that.--Ymblanter (talk) 20:06, 29 December 2015 (UTC)[reply]
There are two qualifiers in use already: a. mouth of the watercourse (P403) b. origin of the watercourse (P885). If there is no qualifier at the coordinate, I think we should asume it as mouth. Wikipedia uses the mouth coordination in the top of wiki pages too and sometimes there are more details coordinates in the river box on the top right side. Important places like cities cite the river not vice versa. e.g. the city Munich (Q1726) has a property located in or next to body of water (P206). --Werner2101 (talk) 07:35, 30 December 2015 (UTC)[reply]
Just stumbled over this river Weser (Q1650) that has the qualifiers applies to part (P518) with the values river mouth (Q1233637) and spring (Q124714) --Werner2101 (talk) 17:59, 31 December 2015 (UTC)[reply]

Beside Weser (Q1650) there is an other methode on this river Saint-Maurice river (Q203862) and an other on this river Chillisquaque Creek (Q1072988) Which one should be used ? --YanikB (talk) 13:50, 30 January 2016 (UTC) This one is awesome Osum (Q83840) :). See also Property_talk:P625#Constraint_violations.[reply]

@Happy5214, Ymblanter, Leyo, Euterpia, Delusion23, Werner2101: I am going to have to suggest that we always put the coordinates under coordinate location (P625) through qualifier applies to part (P518) rather than under origin of the watercourse (P885) or mouth of the watercourse (P403) through qualifier coordinate location (P625), just because we don't always know how to name the river source (Q7376362) or river mouth (Q1233637) and the second method require this. The first one, on the other hand, allows coordinates without specific items attached to them. origin of the watercourse (P885) and mouth of the watercourse (P403) would still be standalone properties on the item, but without coordinate location (P625) as a qualifier. Thierry Caro (talk) 16:06, 14 January 2018 (UTC)[reply]

Which method should we use for coordinate location (P625)[edit]

Method 1 : Saint-Maurice river (Q203862), method 2 : Weser (Q1650), method 3 : Chillisquaque Creek (Q1072988) and method 4 : Osum (Q83840). Since this property should have a single value (Property_talk:P625), we should choose the first one. --YanikB (talk) 13:00, 2 February 2016 (UTC)[reply]

I did some queries to see which people are actually using:
I have personally been using the first option (I didn't even realise other people were doing it in other ways). I'm not keen on coordinate location (P625) with a qualifier because it makes it harder to access the data: With the first option, if you want the coordinates of the mouth, you simply check the P625 qualifier of the P403 statement. With the second and third options, there is no single valid qualifier value you can look for, it's an open-ended list of possible values, which makes it hard to reliably find the coordinates corresponding to the mouth (and, as you can see, people aren't even consistent about which property to use for the qualifier, let alone the value). The fourth option would work in the same way as the first, but it feels weird to me - the coordinates are a property of the mouth, not the other way round. - Nikki (talk) 12:05, 7 April 2016 (UTC)[reply]
See section above for solution. Thierry Caro (talk) 09:13, 21 April 2018 (UTC)[reply]

Graph showing how watercourses go into each other[edit]

I wrote this small query to show what river goes into which one. I limited it to Hungary otherwise it exceeds the server's 30 seconds limit. I am now trying to make it display labels rather than QIDs. With a lot of work it might eventually be usable to find some outliers/anomalies, maybe. Cheers! Syced (talk) 09:52, 11 January 2017 (UTC)[reply]

@Syced: You can change ?name to ?riverLabel to show the label rather than the ID. - Nikki (talk) 17:52, 11 January 2017 (UTC)[reply]
Thanks a lot! Here is the updated query. Syced (talk) 01:39, 12 January 2017 (UTC)[reply]

Duplicates?[edit]

I think we have a duplicate Geonames item that drove the bots to create a duplicate here : Q23708612 and Q23682217. Once merged, w:en:Teusacá River should be added to the remaining item. Louperivois (talk) 15:40, 2 April 2017 (UTC)[reply]

They can not be merged unless the articles get merged on corresponding Wikipedias, which is unlikely to happen.--Ymblanter (talk) 17:04, 4 April 2017 (UTC)[reply]

How to claim, that a human settlement (Q486972) is located on left bank (Q27834806) of watercourse (Q355304)?

Thanks in advance. - Kareyac (talk) 15:21, 11 January 2018 (UTC)[reply]

GNIS ID import for Streams[edit]

I'm working on a GNIS ID import, but there are many entities with close matches. Given the focus of this project is rivers I thought this relevant to announce. See the Mix'n'match link on the Tools page. --Wolfgang8741 (talk) 18:40, 22 June 2018 (UTC)[reply]

Property proposal: Distributary[edit]

There's a proposal for a property for distributaries: Wikidata:Property proposal/distributary. --Yair rand (talk) 18:58, 9 October 2018 (UTC)[reply]

Check queries[edit]

Hi,

For information, I just added some queries to check for common lack and mistake: Wikidata:WikiProject Rivers#Check queries.

Cheers, VIGNERON (talk) 10:49, 10 March 2019 (UTC)[reply]

River who have a confluence as a source[edit]

Hi, the Bras du Nord (Q56739041) is created the junction of the Rivière Sainte-Anne Ouest (Q83716039) and the Rivière Neilson (Q15878734) together. I try to put this fact in puting origin of the watercourse (P885) --> confluence (Q723748). Is it the best practice for this kind of case? --Fralambert (talk) 17:50, 26 January 2020 (UTC)[reply]

Hi,
I see at least 3 solutions :
What do y'all think?
Cheers, VIGNERON (talk) 11:24, 27 January 2020 (UTC)[reply]
The first solution is the standard one for an item with multiple sources. We may add a qualifier to specify the primary source (biggest flow) and secondary sources. --Yanik B 12:04, 27 January 2020 (UTC)[reply]
How to determine the main inflow? We don't always have the flow of the river?. Besides, it's the meeting of A and B who creates C. --Fralambert (talk) 13:49, 27 January 2020 (UTC)[reply]
Usualy the waterway with the highest source (altitude) is the primary source. --Yanik B 18:35, 27 January 2020 (UTC)[reply]
The source of the Mississippi River (Lake Itasca (Q877319)) is neither the longest (Missouri River), the highest (Missouri River again), or the bigest inflow (Ohio River). (And Ohio River (Q4915) is a similar case, since the river begin at the confluence of the Allegheny River (Q686021) and the Monongahela River (Q643780)). The source of a river is often totally arbitrary. --Fralambert (talk) 15:53, 28 January 2020 (UTC)[reply]
Le mississipi n'a pas plusieurs sources. Lorsqu'un cours d'eau a plusieurs sources c'est la source qui a la plus haute altitude qui est la source primaire.--Yanik B 16:45, 28 January 2020 (UTC)[reply]
@YanikB: thank for the comment. I didn't knew that, is it documented somewhere? It really should as it's not really intuitive. Out of curiosity, I did this simple query:
SELECT ?river (COUNT(?source) AS ?nb) {
  ?river wdt:P885 ?source .
}
GROUP BY ?river
HAVING (?nb > 1)
Try it!
There is only a strangely low number of rivers with multiples sources. And, almost none have a qualifier so there is no way to make a distinction between the value which is a very bad idea (problems will ensue).
Cheers, VIGNERON (talk) 16:24, 28 January 2020 (UTC)[reply]
@VIGNERON: As in any statement a property may have several values. I don’t see why it should be done differently for origin of the watercourse (P885). --Yanik B 16:45, 28 January 2020 (UTC)[reply]
@YanikB: yes, exactly, and as for any property with multiple values, the lack of qualifier is problematic. given name (P735) being an obvious case where problem happens. For origin of the watercourse (P885), if I have two values without qualifier (nor rank) : how do I know if there is one or two sources (examples where two values can be one source : an old value and a current one, values coming from differents references, redundancy a general value and a specific one, plain mistake, and so on) and how do I know if it's "value1 and value 2" or "value1 or value2"? Cdlt, VIGNERON (talk) 17:16, 28 January 2020 (UTC)[reply]
Then we should create a qualifier to specify the primary source and secondary source. --Yanik B 17:33, 28 January 2020 (UTC)[reply]
Yes, if we decide to go with this structure, we should. And we need to document it somewhere so other know how to do it next time. Cheers, VIGNERON (talk) 18:15, 28 January 2020 (UTC)[reply]
  • If the origin of the river is another river, it's should be normal that one needs to consider only the last point of that other river (which is the place it changes its name or at a confluence). If there are several, there are several values with the property. Deleting statements wont help with reality .. especially it's one that can be referenced. Obviously, it's possible to qualify the values. --- Jura 16:39, 28 January 2020 (UTC)[reply]

Duplicate properties[edit]

Hi everyone - I'm a bit new here, but I had a question on duplicate properties.

Article Congo (Q3503) had the Congo as an instance of river (Q4022) and watercourse (Q355304) - but 'river' is a subclass of a subclass of 'watercourse'. Is it ok to remove 'watercourse' in this case (since 'river' gives the same and more specific information)? Novokaine (talk) 09:07, 17 January 2022 (UTC)[reply]

@Novokaine Yes, this is ok, since watercourse (Q355304) was uncited. Fralambert (talk) 12:15, 17 January 2022 (UTC)[reply]
My next question might then be expected: is it ok to remove 'watercourse' if you move the citation as well? (I suppose some bots or other logic might rely on the exact tag of "watercourse" existing - but that could be the case for items without citations as well.) Novokaine (talk) 21:23, 9 February 2022 (UTC)[reply]