Hej,
since most of our Swedish Monuments don't have a useful name or address our monument map http://wikilovesmonuments.se/delta-i-tavlingen/hitta-monument/ only shows the id and municipality. This information is often not sufficient enough at all, if you don't know if you are looking for a house of a stone. As the WLM database contains the registrant_url i made a quick fix by copying the WLM api into my toolserver directory and made the ID a link to the registrant_url (see attached patch for include/FormatKml.diff). Is there any nicer way to get the same result, or otherwise if we are not the only ones needing it: Can somebody add the patch to the main API?
Regards, Holger
On 03/09/12 21:21, Holger Motzkau wrote:
Hej,
since most of our Swedish Monuments don't have a useful name or address our monument map http://wikilovesmonuments.se/delta-i-tavlingen/hitta-monument/ only shows the id and municipality. This information is often not sufficient enough at all, if you don't know if you are looking for a house of a stone. As the WLM database contains the registrant_url i made a quick fix by copying the WLM api into my toolserver directory and made the ID a link to the registrant_url (see attached patch for include/FormatKml.diff). Is there any nicer way to get the same result, or otherwise if we are not the only ones needing it: Can somebody add the patch to the main API?
Regards, Holger
The patch was not with the mail (not attached / stripped by the list). Please resend, a path to the patch in your toolserver home would also work.
Regards
Related to this. Is there a way of matching the "name" entry in the database to a combination of list parameters?
To be specific in the case of se-fornmin having name = {{{namn|}}} ({{{raä-nr|}}}, {{{typ|}}}) rather than just the current name = {{{namn|}}}
The problem is that only 7% of the entries in se-fornmin have a {{{namn|}}} parameter. The result in the Android app is empty rows in the list view and empty "ballons" in the map view.
Cheers, Andre / Lokal_Profil
On 3 September 2012 21:28, Platonides platonides@gmail.com wrote:
On 03/09/12 21:21, Holger Motzkau wrote:
Hej,
since most of our Swedish Monuments don't have a useful name or address our monument map http://wikilovesmonuments.se/delta-i-tavlingen/hitta-monument/ only shows the id and municipality. This information is often not sufficient enough at all, if you don't know if you are looking for a house of a stone. As the WLM database contains the registrant_url i made a quick fix by copying the WLM api into my toolserver directory and made the ID a link to the registrant_url (see attached patch for include/FormatKml.diff). Is there any nicer way to get the same result, or otherwise if we are not the only ones needing it: Can somebody add the patch to the main API?
Regards, Holger
The patch was not with the mail (not attached / stripped by the list). Please resend, a path to the patch in your toolserver home would also work.
Regards
Wiki Loves Monuments mailing list WikiLovesMonuments@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments http://www.wikilovesmonuments.org
On 04/09/12 00:19, André Costa wrote:
Related to this. Is there a way of matching the "name" entry in the database to a combination of list parameters?
To be specific in the case of se-fornmin having name = {{{namn|}}} ({{{raä-nr|}}}, {{{typ|}}}) rather than just the current name = {{{namn|}}}
The problem is that only 7% of the entries in se-fornmin have a {{{namn|}}} parameter. The result in the Android app is empty rows in the list view and empty "ballons" in the map view.
Cheers, Andre / Lokal_Profil
Yes. The entry in fill_monuments would roughly look like this: CONCAT(namn, ' (', `raä-nr`, ', ', typ, ')' ) AS name,
If the setting for se-fornmin could be set to that then that should alleviate our problems.
Thanks, Andre / Lokal_Profil
On 3 September 2012 23:27, Platonides platonides@gmail.com wrote:
On 04/09/12 00:19, André Costa wrote:
Related to this. Is there a way of matching the "name" entry in the database to a combination of list parameters?
To be specific in the case of se-fornmin having name = {{{namn|}}} ({{{raä-nr|}}}, {{{typ|}}}) rather than just the current name = {{{namn|}}}
The problem is that only 7% of the entries in se-fornmin have a {{{namn|}}} parameter. The result in the Android app is empty rows in the list view and empty "ballons" in the map view.
Cheers, Andre / Lokal_Profil
Yes. The entry in fill_monuments would roughly look like this: CONCAT(namn, ' (', `raä-nr`, ', ', typ, ')' ) AS name,
Wiki Loves Monuments mailing list WikiLovesMonuments@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments http://www.wikilovesmonuments.org
Not wanting to be that guy, but would it be possible to actually get the name parameter change implemented. Or at least be told if there is a reason why this will not happen/can't happen now.
I've attached two images of the Android app in action which illustrates the problem that this is currently causing us. This is what the was majority of lists/maps look like since the few named entries are swamped by the ~90% which don't have a name parameter.
Hopefully, Andre /Lokal_Profil
On 3 September 2012 23:27, Platonides platonides@gmail.com wrote:
On 04/09/12 00:19, André Costa wrote:
Related to this. Is there a way of matching the "name" entry in the database to a combination of list parameters?
To be specific in the case of se-fornmin having name = {{{namn|}}} ({{{raä-nr|}}}, {{{typ|}}}) rather than just the current name = {{{namn|}}}
The problem is that only 7% of the entries in se-fornmin have a {{{namn|}}} parameter. The result in the Android app is empty rows in the list view and empty "ballons" in the map view.
Cheers, Andre / Lokal_Profil
Yes. The entry in fill_monuments would roughly look like this: CONCAT(namn, ' (', `raä-nr`, ', ', typ, ')' ) AS name,
Wiki Loves Monuments mailing list WikiLovesMonuments@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments http://www.wikilovesmonuments.org
From a quick search through the monument database, there appear to be ~165k
monuments with no name:
mysql> select count(*) from monuments_all where name=''; +----------+ | count(*) | +----------+ | 164796 | +----------+
This affects 18 different countries:
mysql> select distinct country from monuments_all where name=''; +------------+ | country | +------------+ | at | | be-bru | | be-wal | | de-by | | de-he | | de-nrw | | de-nrw-bm | | es | | in | | lu | | mt | | mx | | nl | | no | | ro | | se-fornmin | | sk | | ua | +------------+
All but one of those monuments has data in the 'field': mysql> select count(*) from monuments_all where name='' and source=''; +----------+ | count(*) | +----------+ | 1 | +----------+
If it's too difficult to otherwise determine a name for the monument, perhaps the data could be updated to construct a name based off of the 'title' field in the source, perhaps with an incremented digit appended to it. For instance: http://de.wikipedia.org/w/index.php?title=Liste_der_denkmalgesch%C3%BCtzten_... could become: Liste der denkmalgeschützten Objekte in Sedliská - 01
Or something like that. Rather than hack something into the android app for this, I recommend that this happen in the database itself. That way everyone using the app, including older versions of the app, would be able to see the updated monuments.
I've added this detail and recommendation to the open bug https://bugzilla.wikimedia.org/show_bug.cgi?id=38695.
Arthur
On Fri, Sep 7, 2012 at 7:20 AM, André Costa lokal_profil@hotmail.comwrote:
Not wanting to be that guy, but would it be possible to actually get the name parameter change implemented. Or at least be told if there is a reason why this will not happen/can't happen now.
I've attached two images of the Android app in action which illustrates the problem that this is currently causing us. This is what the was majority of lists/maps look like since the few named entries are swamped by the ~90% which don't have a name parameter.
Hopefully, Andre /Lokal_Profil
On 3 September 2012 23:27, Platonides platonides@gmail.com wrote:
On 04/09/12 00:19, André Costa wrote:
Related to this. Is there a way of matching the "name" entry in the database to a combination of list parameters?
To be specific in the case of se-fornmin having name = {{{namn|}}} ({{{raä-nr|}}}, {{{typ|}}}) rather than just the current name = {{{namn|}}}
The problem is that only 7% of the entries in se-fornmin have a {{{namn|}}} parameter. The result in the Android app is empty rows in the list view and empty "ballons" in the map view.
Cheers, Andre / Lokal_Profil
Yes. The entry in fill_monuments would roughly look like this: CONCAT(namn, ' (', `raä-nr`, ', ', typ, ')' ) AS name,
Wiki Loves Monuments mailing list WikiLovesMonuments@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments http://www.wikilovesmonuments.org
Wiki Loves Monuments mailing list WikiLovesMonuments@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments http://www.wikilovesmonuments.org
On 07/09/12 19:29, Arthur Richards wrote:
From a quick search through the monument database, there appear to be
~165k monuments with no name:
(...)
All but one of those monuments has data in the 'field': mysql> select count(*) from monuments_all where name='' and source=''; +----------+ | count(*) | +----------+ | 1 | +----------+
Source is the wikipedia page. Of course all monuments have one, but that isn't too useful.
That odd monument is in country India, in English, adm1 IN-UP. No other data.
If it's too difficult to otherwise determine a name for the monument, perhaps the data could be updated to construct a name based off of the 'title' field in the source, perhaps with an incremented digit appended to it. For instance: http://de.wikipedia.org/w/index.php?title=Liste_der_denkmalgesch%C3%BCtzten_... could become: Liste der denkmalgeschützten Objekte in Sedliská - 01
Or something like that. Rather than hack something into the android app for this, I recommend that this happen in the database itself. That way everyone using the app, including older versions of the app, would be able to see the updated monuments.
Rather than the full page title, you'd probably want something like "Sedliská - Unnamed 01" or so. But it seems something better done in the local lists than blindly at the db.
The problem is that sometimes the official lists from the government show a monument but not the name. So you know that there's some monument in that city, the id it should have, but absolutely no idea of what it is (of course coordinates are even less likely to appear). And it'd be very hard to find it out. I think that those monuments should simply not be displayed by the app (by default, at least).
They are of interest for the wikipedia lists, but quite useless for WLM. I don't think anyone could come with a photo for them.
If they do have an id (all but that odd Indian entry do), another option would be to use "Unknown monument with id <id>" as name.
While we sort out the bigger issue, meaning decide what to do, could someone fix Andre's problem?
I am not sure if having no name means having no coordinates. If coordinates exist, we should follow Platonides' suggestion about the name ( "Unknown monument with id <id>"), which sounds like something we could do in the app.
Phil
On Fri, Sep 7, 2012 at 2:11 PM, Platonides platonides@gmail.com wrote:
On 07/09/12 19:29, Arthur Richards wrote:
From a quick search through the monument database, there appear to be
~165k monuments with no name:
(...)
All but one of those monuments has data in the 'field': mysql> select count(*) from monuments_all where name='' and source=''; +----------+ | count(*) | +----------+ | 1 | +----------+
Source is the wikipedia page. Of course all monuments have one, but that isn't too useful.
That odd monument is in country India, in English, adm1 IN-UP. No other data.
If it's too difficult to otherwise determine a name for the monument, perhaps the data could be updated to construct a name based off of the 'title' field in the source, perhaps with an incremented digit appended to it. For instance:
http://de.wikipedia.org/w/index.php?title=Liste_der_denkmalgesch%C3%BCtzten_...
could become: Liste der denkmalgeschützten Objekte in Sedliská - 01
Or something like that. Rather than hack something into the android app for this, I recommend that this happen in the database itself. That way everyone using the app, including older versions of the app, would be able to see the updated monuments.
Rather than the full page title, you'd probably want something like "Sedliská - Unnamed 01" or so. But it seems something better done in the local lists than blindly at the db.
The problem is that sometimes the official lists from the government show a monument but not the name. So you know that there's some monument in that city, the id it should have, but absolutely no idea of what it is (of course coordinates are even less likely to appear). And it'd be very hard to find it out. I think that those monuments should simply not be displayed by the app (by default, at least).
They are of interest for the wikipedia lists, but quite useless for WLM. I don't think anyone could come with a photo for them.
If they do have an id (all but that odd Indian entry do), another option would be to use "Unknown monument with id <id>" as name.
Wiki Loves Monuments mailing list WikiLovesMonuments@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments http://www.wikilovesmonuments.org
On Fri, Sep 7, 2012 at 2:43 PM, Philip Chang pchang@wikimedia.org wrote:
While we sort out the bigger issue, meaning decide what to do, could someone fix Andre's problem?
I am not sure if having no name means having no coordinates. If coordinates exist, we should follow Platonides' suggestion about the name ( "Unknown monument with id <id>"), which sounds like something we could do in the app.
Phil
I also think Platonides naming suggestion is a good one, however it is preferable to solve this problem at the data level (either in the monument lists to later get picked up in the db, or just a hack in the db generation scripts), that way it is a universal fix for all app users. If we hack a band-aid fix into the app, it would only be available for folks using the latest version of the app, which means there may continue to be strange errors, etc for folks on outdated app versions. Solving this at the data level means every user (regardless of app version) would see the updated data.
On 07/09/12 23:54, Arthur Richards wrote:
I also think Platonides naming suggestion is a good one, however it is preferable to solve this problem at the data level (either in the monument lists to later get picked up in the db, or just a hack in the db generation scripts), that way it is a universal fix for all app users. If we hack a band-aid fix into the app, it would only be available for folks using the latest version of the app, which means there may continue to be strange errors, etc for folks on outdated app versions. Solving this at the data level means every user (regardless of app version) would see the updated data.
IMHO the db should contain the real data. You can of course modify what wlm.wikimedia.org provides (triggered by an old User-Agent?), you would be perverting the layer functionality, though. Also note that there are I18N issues there, since you'd want to inject the message in a dozen languages depending on the list. Its place is the UI, affected like other translations. :/
At the very least could the name parameter be changed to CONCAT(namn, ' (', `raä-nr`, ')' ) AS name, It reflects the name both as given in our lists, in the source database and in the se-bbr database.
This is less useful than having the type in there as well but it's better than the current situation.
Andre /Lokal_Profil
On 8 September 2012 22:20, Platonides platonides@gmail.com wrote:
On 07/09/12 23:54, Arthur Richards wrote:
I also think Platonides naming suggestion is a good one, however it is preferable to solve this problem at the data level (either in the monument lists to later get picked up in the db, or just a hack in the db generation scripts), that way it is a universal fix for all app users. If we hack a band-aid fix into the app, it would only be available for folks using the latest version of the app, which means there may continue to be strange errors, etc for folks on outdated app versions. Solving this at the data level means every user (regardless of app version) would see the updated data.
IMHO the db should contain the real data. You can of course modify what wlm.wikimedia.org provides (triggered by an old User-Agent?), you would be perverting the layer functionality, though. Also note that there are I18N issues there, since you'd want to inject the message in a dozen languages depending on the list. Its place is the UI, affected like other translations. :/
Wiki Loves Monuments mailing list WikiLovesMonuments@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments http://www.wikilovesmonuments.org
My plan wasn't for an Android hack but rather a change to how the wlm-database matches the entries of the Wikipedia row templates (for se-fornmin). I'm assuming the mapping is done on a case by case basis anyway since the different datasets will include different fields all with different parameter names. In this way the change should fix the Swedish entries (independently of platform) without changing anything for anyone else.
Based on Commons:Monuments_database/Statistics the only other database with few names is de-he which "only" has names for ~45% of the entries (by comparison se-fornmin has 6.25%). The reason I wanted the parameter combination is that the entries are commonly referred to by the {{{raä-nr}}} but only some have a common name (the {{{namn}}} parameter). In the other Swedish database, se-bbr, these were both entered into the {{{namn}}} parameter of the row template to start with, I only split them for se-fornmin because last year we had issues with standardisation in how this should be presented.
Adding the type parameter ({{{typ}}}) to the database name would help clarify what it is that the person is actually looking for, e.g. a runestone, a burial mound, a ruin, i.e. the sort of thing that is normally obvious from the common name where there is one.
Cheers, Andre
On 7 September 2012 22:11, Platonides platonides@gmail.com wrote:
On 07/09/12 19:29, Arthur Richards wrote:
From a quick search through the monument database, there appear to be
~165k monuments with no name:
(...)
All but one of those monuments has data in the 'field': mysql> select count(*) from monuments_all where name='' and source=''; +----------+ | count(*) | +----------+ | 1 | +----------+
Source is the wikipedia page. Of course all monuments have one, but that isn't too useful.
That odd monument is in country India, in English, adm1 IN-UP. No other data.
If it's too difficult to otherwise determine a name for the monument, perhaps the data could be updated to construct a name based off of the 'title' field in the source, perhaps with an incremented digit appended to it. For instance:
http://de.wikipedia.org/w/index.php?title=Liste_der_denkmalgesch%C3%BCtzten_...
could become: Liste der denkmalgeschützten Objekte in Sedliská - 01
Or something like that. Rather than hack something into the android app for this, I recommend that this happen in the database itself. That way everyone using the app, including older versions of the app, would be able to see the updated monuments.
Rather than the full page title, you'd probably want something like "Sedliská - Unnamed 01" or so. But it seems something better done in the local lists than blindly at the db.
The problem is that sometimes the official lists from the government show a monument but not the name. So you know that there's some monument in that city, the id it should have, but absolutely no idea of what it is (of course coordinates are even less likely to appear). And it'd be very hard to find it out. I think that those monuments should simply not be displayed by the app (by default, at least).
They are of interest for the wikipedia lists, but quite useless for WLM. I don't think anyone could come with a photo for them.
If they do have an id (all but that odd Indian entry do), another option would be to use "Unknown monument with id <id>" as name.
Wiki Loves Monuments mailing list WikiLovesMonuments@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments http://www.wikilovesmonuments.org
On Fri, Sep 7, 2012 at 3:04 PM, André Costa lokal_profil@hotmail.comwrote:
My plan wasn't for an Android hack but rather a change to how the wlm-database matches the entries of the Wikipedia row templates (for se-fornmin). I'm assuming the mapping is done on a case by case basis anyway since the different datasets will include different fields all with different parameter names. In this way the change should fix the Swedish entries (independently of platform) without changing anything for anyone else.
Yeah, fair enough - we're talking about different (albeit similar) problems. Regardless though, we need to resolve all issues related to missing monument names.
Hej,
here is the link to the diff: http://toolserver.org/~prolineserver/FormatKml.diff
I also played a little bit with Openstreetmap vs. Google, http://toolserver.org/~prolineserver/map2.php http://toolserver.org/~prolineserver/map3.php but i don't manage to get the popups in OSM smaller...
Regards, Holger
On Mon, Sep 3, 2012 at 10:28 PM, Platonides platonides@gmail.com wrote:
On 03/09/12 21:21, Holger Motzkau wrote:
Hej,
since most of our Swedish Monuments don't have a useful name or address our monument map http://wikilovesmonuments.se/delta-i-tavlingen/hitta-monument/ only shows the id and municipality. This information is often not sufficient enough at all, if you don't know if you are looking for a house of a stone. As the WLM database contains the registrant_url i made a quick fix by copying the WLM api into my toolserver directory and made the ID a link to the registrant_url (see attached patch for include/FormatKml.diff). Is there any nicer way to get the same result, or otherwise if we are not the only ones needing it: Can somebody add the patch to the main API?
Regards, Holger
The patch was not with the mail (not attached / stripped by the list). Please resend, a path to the patch in your toolserver home would also work.
Regards
Wiki Loves Monuments mailing list WikiLovesMonuments@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments http://www.wikilovesmonuments.org
I'd prefer Platonides' database solution.
Maarten
Op 4 sep 2012 om 09:25 heeft Holger Motzkau holger.motzkau@wikimedia.se het volgende geschreven:\
Hej,
here is the link to the diff: http://toolserver.org/~prolineserver/FormatKml.diff
I also played a little bit with Openstreetmap vs. Google, http://toolserver.org/~prolineserver/map2.php http://toolserver.org/~prolineserver/map3.php but i don't manage to get the popups in OSM smaller...
Regards, Holger
On Mon, Sep 3, 2012 at 10:28 PM, Platonides platonides@gmail.com wrote:
On 03/09/12 21:21, Holger Motzkau wrote:
Hej,
since most of our Swedish Monuments don't have a useful name or address our monument map http://wikilovesmonuments.se/delta-i-tavlingen/hitta-monument/ only shows the id and municipality. This information is often not sufficient enough at all, if you don't know if you are looking for a house of a stone. As the WLM database contains the registrant_url i made a quick fix by copying the WLM api into my toolserver directory and made the ID a link to the registrant_url (see attached patch for include/FormatKml.diff). Is there any nicer way to get the same result, or otherwise if we are not the only ones needing it: Can somebody add the patch to the main API?
Regards, Holger
The patch was not with the mail (not attached / stripped by the list). Please resend, a path to the patch in your toolserver home would also work.
Regards
Wiki Loves Monuments mailing list WikiLovesMonuments@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments http://www.wikilovesmonuments.org
Wiki Loves Monuments mailing list WikiLovesMonuments@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments http://www.wikilovesmonuments.org
wikilovesmonuments@lists.wikimedia.org
