Hi! I was wondering how inaccurate coordinates of heliports like Manatee Memorial Hospital heliport (Q74841828) could have been imported? The FAA airport code places this heliport a hundred meters or so to the west. Seen this in a couple of other heliports as well. Would it be possible to correct this in a batch? This seems to be reoccuring in the Second USA edit set.
User talk:Bouzinac
About this board
Welcome to Wikidata, Bouzinac!
Wikidata is a free knowledge base that you can edit! It can be read and edited by humans and machines alike and you can go to any item page now and add to this ever-growing database!
Need some help getting started? Here are some pages you can familiarize yourself with:
- Introduction – An introduction to the project.
- Wikidata tours – Interactive tutorials to show you how Wikidata works.
- Community portal – The portal for community members.
- User options – including the 'Babel' extension, to set your language preferences.
- Contents – The main help page for editing and using the site.
- Project chat – Discussions about the project.
- Tools – A collection of user-developed tools to allow for easier completion of some tasks.
Please remember to sign your messages on talk pages by typing four tildes (~~~~); this will automatically insert your username and the date.
If you have any questions, please ask me on my talk page. If you want to try out editing, you can use the sandbox to try. Once again, welcome, and I hope you quickly feel comfortable here, and become an active editor for Wikidata.
Best regards! Liuxinyu970226 (talk) 09:26, 28 March 2016 (UTC)
Previous discussion was archived at User talk:Bouzinac/Archive 1 on 2018-08-08.
hi there, I no longer remember how I did build the file, but certainly there might have been a mistake somewhere. Or perhaps data has changed between 2019 and now... Or perhaps people did (inadvertently) remove "duplicated" coordinates. I have just checked and it appears FAA no longer propose Excel file for US airports...
I don't think multiple heliports moved ~ 100m westwards in the past few years. Airport Data and Information Portal has a download all records link at the top of the page.
No but perhaps the data was then inaccurate, or other reasons. Didn't notice the new link. I'll try to update the coordinates...
I've made the new Airport Data and Information Portal (Q108870105) item so you can state it as a reference using the stated in (P248) and retrieved (P813) properties.
These broken heliport items are a mess. It is going to take a lot of work to fix them. Coordinates are wrong, so we should remove them for now. Somebody needs to take responsibility for maintaining these items. When the maintainer of these items has time they can add the correct coordinates.
I have randomly selected heliports USA, and I didnt find so much inaccuracies. Plus, they occur time to time, not even due to the "second usa" batch. For instance, that one with false coordinates from enwiki : Rainier Heliport(Q428415) with coordinates (and name...) very different from CACHE CREEK USFS (faa.gov)
Here a full list of open US héliports : query and it should be compared to the https://adip.faa.gov/agis/public/#/airportSearch/advanced
I don't know how to match difference of coordinates in Excel... is there a formula to compute coords differences ?
Plus there is apparently roughly ~250 heliports in FAA list, not being on Wikidata. Some examples : CN55 1AK9 AL85
In OpenRefine you can import a table and reconcile it with Wikidata based on the FAA code. You can then retrieve the coordinate linked to that item. This comes back as a comma lat/long annotation: 52.004,34.099. GIS software like QGIS could be used to change this ARP format in the spreadsheet.
enwiki is sometimes false... just have a look between https://en.wikipedia.org/wiki/Turel_Heliport and Turel Heliport (Q7854841) and https://nfdc.faa.gov/nfdcApps/services/ajv5/airportDisplay.jsp?airportId=OR03 ...
Yeah would prefer FAA data over an import from enwiki
What to think about IL73 ? Q61667466 : i've supposed this helistation has ceased since IL73 is not on the FAA directory.
the corresponding hospital, HSHS St. Elizabeth's Hospital (Q108896859), is a fair bit to the north east so I guess it's safe to say this heliport was discontinued when it relocated.
The Red Lines are not part of the Bangkok MRT - see https://en.wikipedia.org/wiki/MRT_(Bangkok) - it only encompasses the Blue and Purple lines. ~~~~
Hi, MRT (Q806485) should be understood wider, such as in that map https://en.wikipedia.org/wiki/Mass_Rapid_Transit_Master_Plan_in_Bangkok_Metropolitan_Region#/media/File:Bkk_masstransit_2020_clear_version_english_wiki-01.png For example, "Paris subway" can count both subways and suburbans trains.
That would be Q7283953 or Q387067. All the statements on Q806485 are specifically for the MRT lines only (e.g. map, opening date, operator, has part)
The labels of items you created are wrong. All station names in Chinese should be ending with 站 (or 車站, which applies to heavy-rail station in Taiwan).
When reading list such as https://zh.wikipedia.org/wiki/%E8%8B%8F%E5%B7%9E%E8%BD%A8%E9%81%93%E4%BA%A4%E9%80%9A3%E5%8F%B7%E7%BA%BF they rarely end in 站. So you are free to correct as I don't speak Chinese...
Any guess on how to import a file with GPS for that list https://en.wikipedia.org/wiki/Line_3_(Wuxi_Metro) ? And oh, if you could have a see at that query https://w.wiki/3NU$ and add qualifying correct P31 ?
Dear Bouzinac,
I hope you are doing good,
I am Kholoud, a researcher at the King’s College London, and I work on a project as part of my PhD research that develops a personalized recommendation system to suggest Wikidata items for the editors based on their interests and preferences. I am collaborating on this project with Elena Simperl and Miaojing Shi.
I would love to talk with you to know about your current ways to choose the items you work on in Wikidata and understand the factors that might influence such a decision. Your cooperation will give us valuable insights into building a recommender system that can help improve your editing experience.
Participation is completely voluntary. You have the option to withdraw at any time. Your data will be processed under the terms of UK data protection law (including the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018). The information and data that you provide will remain confidential; it will only be stored on the password-protected computer of the researchers. We will use the results anonymized (?) to provide insights into the practices of the editors in item selection processes for editing and publish the results of the study to a research venue. If you decide to take part, we will ask you to sign a consent form, and you will be given a copy of this consent form to keep.
If you’re interested in participating and have 15-20 minutes to chat (I promise to keep the time!), please either contact me on kholoudsaa@gmail.com or use this form https://docs.google.com/forms/d/e/1FAIpQLSdmmFHaiB20nK14wrQJgfrA18PtmdagyeRib3xGtvzkdn3Lgw/viewform?usp=sf_link with your choice of the times that work for you.
I’ll follow up with you to figure out what method is the best way for us to connect.
Please contact me using the email mentioned above if you have any questions or require more information about this project.
Thank you for considering taking part in this research.
Regards
Kholoud
Hi Bouzinac,
You recently reverted edits of mine:
- Q239927 (Catania Metro, Italy)
- Q320337 (Yerevan Metro, Armenia)
- Q805751 (Metro SubwayLink, Baltimore, USA)
- Q1163754 (Genoa Metro, Italy)
- Q1577126 (Tren Urbano, San Juan, Puerto Rico)
All of these are rapid transit systems consisting of a single line, so in my understanding they are both / should be instances of both:
You removed the "Instance of: Rapid transit railway line" for these 5 when you reverted my edits.
I see that initially one might wonder about the validity of such dual InstanceOf, and i myself have reverted similar cases of dual InstanceOf once they popped up in data quality queries of mine, but in these cases i see clear validity of such dual instanceOf.
To not start an edit war i want to find consensus with you here for this topic.
Best regards,
RScheiber
Hi there, the problem is not with rapid transit railway line (Q15079663) or rapid transit (Q5503). Yes, these system (Catania, Yerevan, etc) do have only one line. But, these systems might have one day another lines. So I'd rather always separate
- the "line" function (the fact that a train goes from A to B to C, etc)
- They might have specific properties and a station A would have connecting line (P81) = "this line" Example : Q106334371 . So P81 needs an item being Q15079663 (Rapid transit railway line)
- the "subway" function (the whole system, which can be not only the subway but also buses, or even tramways possibly). Example : Q239927 (Catania Metro, Italy)
- They might have specific properties and a station A would have part of (P361) = "the subway" The perfect example to illustrate that is Porto metro station (Q3909129) : that old station is forever part of Q239927. But it has never been on the current existing line Q15079663. That's why I separated lines/subway system to the items you mentioned.
- If you wish to see that phenomenon, you could check that query for italian subways stations: https://w.wiki/3QAD
- If you wish to add lines to P361, feel free to do so. But please put only purely lines items inside the P81.
Cheers,
Hi Bouzinac,
I can see why you want to split Babylon in two entities (even though that introduces other problems and I would not have done it this way). But, given that most Wikipedia articles are probably about the site rather than the country (political entity/city-state/whatever you want to call it), and given that the site is much more well known, I would suggest to make Babylon (Q5684) the item about the site and the new one Babylon (Q100329356) about the political entity. So exactly the other way around than what you did. What do you think?
Hi there ; Q number should not be a reference per se (merge, move, etc) ; but Wikidata must be storing the singlest concept. So indeed a Q for the site (when was it discovered, where, what time can we visit it, etc) and for the old country (who did rule it, whom country did it went war with, etc). What are the problem exactly ? If you find a wiki speaking mostly about the site rather than the old country, you can move the wikipage to the relevant Q
I know it isn't a reference, but for (just one) example, is about the site, whereas , which is First Babylonian Empire (Q733897), is about one of the states that emerged from Babylon. So actually you created an entity that already exists, and that is not the singlest concept at all. The concept of Babylon is not so simple as just a site and a state. It is much more complex than that. Keeping it all in one item is not a good solution, but creating a new item without doing any cleanup isn't any better either - or at least that's what I think. So again, I would leave the information about the site at Babylon (Q5684) as that better reflects the existing links from Wikipedia, and the historical contents of Q5684 as well. Best,
? Babylon as strictly archealogical site didn't exist? I'm no specialist of babylonian history but https://w.wiki/3enC looks OK. As always, WD needs some cleaning, with Q16630263 for instance.
Well, it sort of existed at Babylon (Q5684), until you split it off. So again, rather than creating a new item, it would have been better to split off the information on the political states from Q5684 to other already existing entities, such as First Babylonian Empire (Q733897). So my suggestion is: merge your item back into Q5684 and then update some of the other relevant items. Your new item complicates matters more than that it solves issues, I believe. Best,
Hi ChristianKl (talk • contribs • logs), what do you think about Zoeperkoe remarks ?
Just to be clear: I think that Babylon (Q5684) should be about Babylon as a city; it would have (for example) P31=archaeological site and P31=human settlement (with start-end dates) and P31=capital (if that exists, with, start-end dates) and it would have the UNESCO World Heritage site info. It would not have the values P31=historical country and P31=sovereign state. These would be moved to, for example, First Babylonian Empire (Q733897) and other entities about Babylonian empires (leaving aside the question that a clear-cut distinction between capital and state works for modern states, but not ancient ones like Babylon).
The reason that I think Q5684 should be about the site is that most Wikipedia articles linking to it are about the site, as well as the external identifiers and a quite a few other properties.
This would also mean that all information that is now in Babylon (Q100329356) will be moved back to Q5684, just as it was before Q100329356 was created.
By the way, the same goes for Ugarit (Q191369).
Babylon is a city (or human settlement) that existed 1000 AD. No archeological site for Babylon existed at that time. If there's an entity that exists today that's an archaeological site and part of the UNESCO World Heritage that's a different entity then the city of Babylon and thus deserves a different item.
Wikipedia is irrelevant to the question of whether to have one or more Wikidata items.
I don't know enough about Bablyon to say whether it makes sense to seperate a city of Babylon from a state of Babylon
@ChristianKl You say: "If there's an entity that exists today that's an archaeological site and part of the UNESCO World Heritage that's a different entity then the city of Babylon and thus deserves a different item." Just to get this clear: why? Why do you think that splitting them is a better solution than keeping the city and archaeological site in one item and solving this with start/end dates on the property instance of=city?
Because Wikidata is about the singlest concept. If you mix them, you would have both "this is a ruin" + "this has been demolished at year YYYY" AND "this was a city, populated with XXX people, capital of state XXX" Obviously, you cannot pretend a ruin was a capital at same time and that the ruins were demolished at year YYYY.
That depends on how you model it. So, just to be clear: are you saying that every item about every archaeological site on Wikidata needs to be split in two because they cannot be an archaeological site and a human settlement (or city, or temple, or whatever) "at the same time"?
Yes : it is clearly stated there https://www.wikidata.org/wiki/Help:Items You just don't mix carrot and cabbages in the same field.
So if I understand you correctly, you argue that every item about every archaeological site should be split. Would you mind if I post this question, whether tens of thousands of items about archaeological sites should be split, on the project chat to get some more feedback on this?
Yes, in fact. There is just ~200 archeological sites having dissolved, abolished or demolished date (P576) https://w.wiki/3f4P And only 24 sites being P31 both archeological site + old city https://w.wiki/3f4U Isn't it weird to see statements that that arch. site X was demolished XXXX years ago ? Isn't it weird to see statements that that arch. site X was founded XXXX years ago ?
Sure, that might be weird. But the problem there lies in those statements, and not in the fact that there's only one item about an archaeological site. If those statements were used, for example, as qualifiers to the statement instance of=city, then that would be much better already. So instead of splitting items off, it would be better to change those statements because many of them are just wrong in the way that they are implemented now.
I've taken the liberty of posting the general question on whether archaeological sites should be split, like you suggest, here: Wikidata:Project chat#Modelling archaeological sites
The city and the archeological site existed at different points of time. Splitting enitites in multiple items is standard procedure for Wikidata. In Wikipedia it frequently makes sense to mix multiple entities together.
In Wikidata it's very useful if items share formatting. Your suggestion means that it gets much harder to run a query for settlements that were dissolved before year X.
I would suggest that the problem is not in splitting city/archaeological site, but that the problem lies in the use of the statement "dissolved" (and the likes) to describe what happens at an archaeological site... But I would prefer to keep this discussion in one place, and I would suggest to make that place Wikidata:Project chat#Modelling archaeological sites instead of here. Thanks!
That's because the enwiki article isn't updated according to this.
Are you sure about https://www.wikidata.org/wiki/Q107580086#P197 ?
The new naming plans of stations are shown here. Here is the new map of Line 17.
Ok, there was a typo in frlabel of https://www.wikidata.org/wiki/Q105802536#lang=fr
Please do not change the colors of Cairo Metro line. The original colors used in Cairo are red (line 1), orange (line 2), green (line 3), purple (line 4), brown (line 5), blue (line 6). See also: https://commons.wikimedia.org/wiki/File:%D9%85%D8%AA%D8%B1%D9%88_%D8%A7%D9%84%D9%82%D8%A7%D9%87%D8%B1%D8%A9_%DB%B2%DB%B0%DB%B1%DB%B9_%DB%B1%DB%B2_%DB%B0%DB%B2.png. The colors used in some Wikipedias are wrong.
Sorry, but the official website is there https://cairometro.gov.eg/en/Maps .
Plus, there is apparently another new official map (with slightly same coulours palette) https://www.cairoscene.com/Buzz/Transport-for-Cairo-Designs-New-Map-for-Metro-Line-3
But the maps at the metro stations show red, orange, and green since docents of years. I do not know why different colors are shown at the web page. This is really confusing, at least for travelers. In the past months, I could not found an (English) news article describing the change of colors. Maybe we should ask Egyptian authors to check the real colors before the change of Wikidata.
I sent some letters to several people including Cairo Metro organization to learn which colors are now correct.
Because of M2 (Q56399732)
Maybe you can consult User:Liuxingy for help, for he is a Xi'an local. I can only help some of the stations by using OSM.
Yeah, OSM is sometimes not up to date or labels are only in Chinese and it's hard to guess which station is about
And the goal is to help finish that kind of map
Well I forgot to say that I may combine OSM with Amap or Baidu Maps according to street intersections.
Hello, i'm a bit confused by Daxing line(Q5242742) and Line 4(Q304264)... Are they in fact same subway line?
Not exactly the same line, but under a same system: Line 4 from Anheqiao Bei (N) to Gongyi Xiqiao, and Daxing Line from Xin Gong to Tiangong Yuan, but most of the trains run through services with Anheqiao Bei (N) as left terminus and Tiangong Yuan as right terminus. Moreover, the official website of Beijing MTR Corporation Limited and its timetable labels the system as "Line 4-Daxing Line", so please don't make changes relating to "connecting line" and "adjacent station" when it comes to this situation.
It's an unsatisfaying situation given the still-work-in-progress map https://www.wikidata.org/wiki/Talk:Q235319 It's my comprehension that Line 4 and Daxing have same tracks, but not same service : trains run same departure and may end not at the same terminus. I think all the stations should have Daxing + L4 where they have service. Finally, L4 has become a subway line branch (Q106793561), hasn't it?
See their articles on zhwiki and even enwiki, especially their "adjacent station" in infoboxes.
Moreover: The images of exits along Line 4 and Daxing Line can be found on Commons, depicting how they are marked. Another similar example, I think, is the Keihin-Tohoku Line and Negishi Line, where stations north of Yokohama are not belonging to the latter.
Not this case: Residents along Daxing Line often call it "Line 4".
Another similar problem : Chengjiao Line (Q28441548)
There are plans that Chengjiao Line would be merged into Line 9.