Re: [OSM-talk] Many processes not defined | Re: Proposal for Software Dispute Resolution Panel
I meant, that the board hasn't decided how the board will vote/appoint/choose the members of this panel. On 05/08/2020 01:07, Christoph Hormann wrote: On Tuesday 04 August 2020, Rory McCann wrote: The Board hasn't decided on how the panel will be formed/elected/appointed/choosen. Quoting from the proposal: In appointing members of the Panel, the Board shall strive for Panel composition (membership) that reflects [...] Seems there are some eddies in the fabric of spacetime... <>___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Many processes not defined | Re: Proposal for Software Dispute Resolution Panel
On Tuesday 04 August 2020, Rory McCann wrote: > The Board hasn't decided on how the panel will be > formed/elected/appointed/choosen. Quoting from the proposal: > In appointing members of the Panel, the Board shall strive for Panel composition (membership) that reflects [...] Seems there are some eddies in the fabric of spacetime... -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Many processes not defined | Re: Proposal for Software Dispute Resolution Panel
More seriously the line “all interests of the OSM community” was one we talked a lot about on the board when writing this message, and had several versions, and indeed we touched on how to best designate what was needed in composition of the panel. I think it’s not possible to put together a specific formula, but think we should expand this section to touch on the kinds of things we would hope to see in the composition of the board. That certainly would be experience and expertise with OSM community and software development and mapping. I don’t think anyone is impartial on anything but we’d want people who are recognized as open minded. We haven’t talked at all about transparency of selection and deliberations. I’m not sure it’s wise to be completely open in the work of disputes, but certainly having deliberations well minutes and explained makes sense. Mikel On Tuesday, August 4, 2020, 5:42 PM, Mikel Maron wrote: It was a joke more aimed at Rory and a continuation of the similar discussion we’ve had on the board. And yes I agree very much with the sentiment that we don’t want OSM to be dominated by companies. or any single point of view for that matter. I’ve come to not like that quote because I don’t believe it’s often the case. And I think that there’s a lot of decisions which are favorable to all involved in osm, whether giant company or a single mapper. The dichotomy is not that pronounced if you look closely. Mikel On Tuesday, August 4, 2020, 5:31 PM, Joseph Eisenberg wrote: Re: "Rory, I don't know about you, but I'm certainly hoping for a bunch of corporate sell outs rubber stamping iD decisions and squashing the common mapper into conformity. Why else would we be doing this?" This sarcastic comment is not a fair response to Christoph's concerns. While we hope that no one involved currently in OpenStreetMap would purposefully turn the community over to corporations, it is certainly possible to imagine this to happen little by little, if the community is eroded slowly, lacking safeguards and clear goals. If the people who become leaders of the OpenStreetMap community have all of their experience and ideals based in the corporate tech sector, it will be unsurprising if they are naturally inclined to make decisions which are favorable to the interests of Facebook, Apple or Amazon, whether or not they benefit the OpenStreetMap community. As a famous American reformer (Upton Sinclair) often said: "It is difficult to get a man to understand something, when his salary depends upon his not understanding it." – Joseph Eisenberg On Tue, Aug 4, 2020 at 2:08 PM Mikel Maron wrote: Rory, I don't know about you, but I'm certainly hoping for a bunch of corporate sell outs rubber stamping iD decisions and squashing the common mapper into conformity. Why else would we be doing this? On Tuesday, August 4, 2020, 04:37:00 PM EDT, Rory McCann wrote: The Board hasn't decided on how the panel will be formed/elected/appointed/choosen. Just because the document doesn't address one issue, doesn't mean the opposite, horrible option will happen. Do you think I'm going to support some Old Boy's Network of corporate employees? What would you suggest for appointing & transparency? On 04.08.20 21:30, Christoph Hormann wrote: > On Tuesday 04 August 2020, Dorothea Kazazi wrote: >> >> The OSMF board just published a proposal for a software >> dispute resolution panel: >> https://blog.openstreetmap.org/2020/08/04/proposal-for-software-dispu >> te-resolution-panel/ > > I guess i am asking too much if i envision the board creating a panel it > does not control itself... > > For context - the DWG, which is the traditional and broadly respected > entity to resolve conflicts in mapping, is not controlled in > composition by the board, it decides on accepting new members > themselves. See also: > > https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Membership_Policy > https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Conflict_of_Interest_Policy > > Significant parts of the authority the DWG has among mappers derive from > the fact that it is not composed of political appointees. > > Interesting also that the composition of the panel is supposed to > reflect "all interests of the OSM community" but competence of the > panel members on the subject, experience with and knowledge of mapping > and tagging in OSM or in other words: The competence to assess > evidence on the cases they deal with and to deliberate on the matters > in a qualified and knowledgable way, is not a criterion. Neither is > impartiality on prominent special interests like those of corporate > data users. > > Transparency is limited to the ultimate decisions being made public > (indeed important, would be interesting how this would function > otherwise). I guess that means both the nominations and selection of > panel members as well as the deliberation and consulting of the panel > on cases i
Re: [OSM-talk] Many processes not defined | Re: Proposal for Software Dispute Resolution Panel
It was a joke more aimed at Rory and a continuation of the similar discussion we’ve had on the board. And yes I agree very much with the sentiment that we don’t want OSM to be dominated by companies. or any single point of view for that matter. I’ve come to not like that quote because I don’t believe it’s often the case. And I think that there’s a lot of decisions which are favorable to all involved in osm, whether giant company or a single mapper. The dichotomy is not that pronounced if you look closely. Mikel On Tuesday, August 4, 2020, 5:31 PM, Joseph Eisenberg wrote: Re: "Rory, I don't know about you, but I'm certainly hoping for a bunch of corporate sell outs rubber stamping iD decisions and squashing the common mapper into conformity. Why else would we be doing this?" This sarcastic comment is not a fair response to Christoph's concerns. While we hope that no one involved currently in OpenStreetMap would purposefully turn the community over to corporations, it is certainly possible to imagine this to happen little by little, if the community is eroded slowly, lacking safeguards and clear goals. If the people who become leaders of the OpenStreetMap community have all of their experience and ideals based in the corporate tech sector, it will be unsurprising if they are naturally inclined to make decisions which are favorable to the interests of Facebook, Apple or Amazon, whether or not they benefit the OpenStreetMap community. As a famous American reformer (Upton Sinclair) often said: "It is difficult to get a man to understand something, when his salary depends upon his not understanding it." – Joseph Eisenberg On Tue, Aug 4, 2020 at 2:08 PM Mikel Maron wrote: Rory, I don't know about you, but I'm certainly hoping for a bunch of corporate sell outs rubber stamping iD decisions and squashing the common mapper into conformity. Why else would we be doing this? On Tuesday, August 4, 2020, 04:37:00 PM EDT, Rory McCann wrote: The Board hasn't decided on how the panel will be formed/elected/appointed/choosen. Just because the document doesn't address one issue, doesn't mean the opposite, horrible option will happen. Do you think I'm going to support some Old Boy's Network of corporate employees? What would you suggest for appointing & transparency? On 04.08.20 21:30, Christoph Hormann wrote: > On Tuesday 04 August 2020, Dorothea Kazazi wrote: >> >> The OSMF board just published a proposal for a software >> dispute resolution panel: >> https://blog.openstreetmap.org/2020/08/04/proposal-for-software-dispu >> te-resolution-panel/ > > I guess i am asking too much if i envision the board creating a panel it > does not control itself... > > For context - the DWG, which is the traditional and broadly respected > entity to resolve conflicts in mapping, is not controlled in > composition by the board, it decides on accepting new members > themselves. See also: > > https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Membership_Policy > https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Conflict_of_Interest_Policy > > Significant parts of the authority the DWG has among mappers derive from > the fact that it is not composed of political appointees. > > Interesting also that the composition of the panel is supposed to > reflect "all interests of the OSM community" but competence of the > panel members on the subject, experience with and knowledge of mapping > and tagging in OSM or in other words: The competence to assess > evidence on the cases they deal with and to deliberate on the matters > in a qualified and knowledgable way, is not a criterion. Neither is > impartiality on prominent special interests like those of corporate > data users. > > Transparency is limited to the ultimate decisions being made public > (indeed important, would be interesting how this would function > otherwise). I guess that means both the nominations and selection of > panel members as well as the deliberation and consulting of the panel > on cases is going to happen behind closed doors. > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Many processes not defined | Re: Proposal for Software Dispute Resolution Panel
Re: "Rory, I don't know about you, but I'm certainly hoping for a bunch of corporate sell outs rubber stamping iD decisions and squashing the common mapper into conformity. Why else would we be doing this?" This sarcastic comment is not a fair response to Christoph's concerns. While we hope that no one involved currently in OpenStreetMap would purposefully turn the community over to corporations, it is certainly possible to imagine this to happen little by little, if the community is eroded slowly, lacking safeguards and clear goals. If the people who become leaders of the OpenStreetMap community have all of their experience and ideals based in the corporate tech sector, it will be unsurprising if they are naturally inclined to make decisions which are favorable to the interests of Facebook, Apple or Amazon, whether or not they benefit the OpenStreetMap community. As a famous American reformer (Upton Sinclair) often said: "It is difficult to get a man to understand something, when his salary depends upon his not understanding it." – Joseph Eisenberg On Tue, Aug 4, 2020 at 2:08 PM Mikel Maron wrote: > Rory, I don't know about you, but I'm certainly hoping for a bunch of > corporate sell outs rubber stamping iD decisions and squashing the common > mapper into conformity. Why else would we be doing this? > > On Tuesday, August 4, 2020, 04:37:00 PM EDT, Rory McCann < > r...@technomancy.org> wrote: > > > > > > The Board hasn't decided on how the panel will be > formed/elected/appointed/choosen. Just because the document doesn't > address one issue, doesn't mean the opposite, horrible option will > happen. Do you think I'm going to support some Old Boy's Network of > corporate employees? > > What would you suggest for appointing & transparency? > > On 04.08.20 21:30, Christoph Hormann wrote: > > On Tuesday 04 August 2020, Dorothea Kazazi wrote: > >> > >> The OSMF board just published a proposal for a software > >> dispute resolution panel: > >> https://blog.openstreetmap.org/2020/08/04/proposal-for-software-dispu > >> te-resolution-panel/ > > > > I guess i am asking too much if i envision the board creating a panel it > > does not control itself... > > > > For context - the DWG, which is the traditional and broadly respected > > entity to resolve conflicts in mapping, is not controlled in > > composition by the board, it decides on accepting new members > > themselves. See also: > > > > > https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Membership_Policy > > > https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Conflict_of_Interest_Policy > > > > Significant parts of the authority the DWG has among mappers derive from > > the fact that it is not composed of political appointees. > > > > Interesting also that the composition of the panel is supposed to > > reflect "all interests of the OSM community" but competence of the > > panel members on the subject, experience with and knowledge of mapping > > and tagging in OSM or in other words: The competence to assess > > evidence on the cases they deal with and to deliberate on the matters > > in a qualified and knowledgable way, is not a criterion. Neither is > > impartiality on prominent special interests like those of corporate > > data users. > > > > Transparency is limited to the ultimate decisions being made public > > (indeed important, would be interesting how this would function > > otherwise). I guess that means both the nominations and selection of > > panel members as well as the deliberation and consulting of the panel > > on cases is going to happen behind closed doors. > > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Many processes not defined | Re: Proposal for Software Dispute Resolution Panel
Mikel, I might be misunderstanding what you meant, but in my opinion conformity is required for this type of project, and I do hope iD/JOSM/... help us achieve that. To clarify: * features with the same meaning (type) should be mapped the same way, otherwise each consumer must understand all of them, and only large corporations will be able to hire enough people to parse & handle it all. * it should be relatively simple for the community to add new types, and later to converge on how to map that new type, thus becoming a new "standard". * multiple editors should encourage users to map the same types of features in the same way. So yes, conformity is good because it allows us (consumers) to make sense of the data without having an army of developers. Hope I'm making sense here, and stating the obvious. Captain out. :) On Tue, Aug 4, 2020 at 5:08 PM Mikel Maron wrote: > Rory, I don't know about you, but I'm certainly hoping for a bunch of > corporate sell outs rubber stamping iD decisions and squashing the common > mapper into conformity. Why else would we be doing this? > > On Tuesday, August 4, 2020, 04:37:00 PM EDT, Rory McCann < > r...@technomancy.org> wrote: > > > > > > The Board hasn't decided on how the panel will be > formed/elected/appointed/choosen. Just because the document doesn't > address one issue, doesn't mean the opposite, horrible option will > happen. Do you think I'm going to support some Old Boy's Network of > corporate employees? > > What would you suggest for appointing & transparency? > > On 04.08.20 21:30, Christoph Hormann wrote: > > On Tuesday 04 August 2020, Dorothea Kazazi wrote: > >> > >> The OSMF board just published a proposal for a software > >> dispute resolution panel: > >> https://blog.openstreetmap.org/2020/08/04/proposal-for-software-dispu > >> te-resolution-panel/ > > > > I guess i am asking too much if i envision the board creating a panel it > > does not control itself... > > > > For context - the DWG, which is the traditional and broadly respected > > entity to resolve conflicts in mapping, is not controlled in > > composition by the board, it decides on accepting new members > > themselves. See also: > > > > > https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Membership_Policy > > > https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Conflict_of_Interest_Policy > > > > Significant parts of the authority the DWG has among mappers derive from > > the fact that it is not composed of political appointees. > > > > Interesting also that the composition of the panel is supposed to > > reflect "all interests of the OSM community" but competence of the > > panel members on the subject, experience with and knowledge of mapping > > and tagging in OSM or in other words: The competence to assess > > evidence on the cases they deal with and to deliberate on the matters > > in a qualified and knowledgable way, is not a criterion. Neither is > > impartiality on prominent special interests like those of corporate > > data users. > > > > Transparency is limited to the ultimate decisions being made public > > (indeed important, would be interesting how this would function > > otherwise). I guess that means both the nominations and selection of > > panel members as well as the deliberation and consulting of the panel > > on cases is going to happen behind closed doors. > > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Many processes not defined | Re: Proposal for Software Dispute Resolution Panel
Rory, I don't know about you, but I'm certainly hoping for a bunch of corporate sell outs rubber stamping iD decisions and squashing the common mapper into conformity. Why else would we be doing this? On Tuesday, August 4, 2020, 04:37:00 PM EDT, Rory McCann wrote: The Board hasn't decided on how the panel will be formed/elected/appointed/choosen. Just because the document doesn't address one issue, doesn't mean the opposite, horrible option will happen. Do you think I'm going to support some Old Boy's Network of corporate employees? What would you suggest for appointing & transparency? On 04.08.20 21:30, Christoph Hormann wrote: > On Tuesday 04 August 2020, Dorothea Kazazi wrote: >> >> The OSMF board just published a proposal for a software >> dispute resolution panel: >> https://blog.openstreetmap.org/2020/08/04/proposal-for-software-dispu >> te-resolution-panel/ > > I guess i am asking too much if i envision the board creating a panel it > does not control itself... > > For context - the DWG, which is the traditional and broadly respected > entity to resolve conflicts in mapping, is not controlled in > composition by the board, it decides on accepting new members > themselves. See also: > > https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Membership_Policy > https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Conflict_of_Interest_Policy > > Significant parts of the authority the DWG has among mappers derive from > the fact that it is not composed of political appointees. > > Interesting also that the composition of the panel is supposed to > reflect "all interests of the OSM community" but competence of the > panel members on the subject, experience with and knowledge of mapping > and tagging in OSM or in other words: The competence to assess > evidence on the cases they deal with and to deliberate on the matters > in a qualified and knowledgable way, is not a criterion. Neither is > impartiality on prominent special interests like those of corporate > data users. > > Transparency is limited to the ultimate decisions being made public > (indeed important, would be interesting how this would function > otherwise). I guess that means both the nominations and selection of > panel members as well as the deliberation and consulting of the panel > on cases is going to happen behind closed doors. > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Many processes not defined | Re: Proposal for Software Dispute Resolution Panel
The Board hasn't decided on how the panel will be formed/elected/appointed/choosen. Just because the document doesn't address one issue, doesn't mean the opposite, horrible option will happen. Do you think I'm going to support some Old Boy's Network of corporate employees? What would you suggest for appointing & transparency? On 04.08.20 21:30, Christoph Hormann wrote: On Tuesday 04 August 2020, Dorothea Kazazi wrote: The OSMF board just published a proposal for a software dispute resolution panel: https://blog.openstreetmap.org/2020/08/04/proposal-for-software-dispu te-resolution-panel/ I guess i am asking too much if i envision the board creating a panel it does not control itself... For context - the DWG, which is the traditional and broadly respected entity to resolve conflicts in mapping, is not controlled in composition by the board, it decides on accepting new members themselves. See also: https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Membership_Policy https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Conflict_of_Interest_Policy Significant parts of the authority the DWG has among mappers derive from the fact that it is not composed of political appointees. Interesting also that the composition of the panel is supposed to reflect "all interests of the OSM community" but competence of the panel members on the subject, experience with and knowledge of mapping and tagging in OSM or in other words: The competence to assess evidence on the cases they deal with and to deliberate on the matters in a qualified and knowledgable way, is not a criterion. Neither is impartiality on prominent special interests like those of corporate data users. Transparency is limited to the ultimate decisions being made public (indeed important, would be interesting how this would function otherwise). I guess that means both the nominations and selection of panel members as well as the deliberation and consulting of the panel on cases is going to happen behind closed doors. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for Software Dispute Resolution Panel
Hi, On 8/4/20 21:30, Christoph Hormann wrote: > Significant parts of the authority the DWG has among mappers derive from > the fact that it is not composed of political appointees. Speaking as a DWG member, I always hoped that people would judge us by the work we do, not how we got the job ;) And about the matter at hand, the DWG has been asked whether they would like to take on this extra responsibility and we have not yet responded with anything definitive. On the one hand, this extra job would use more of our resources and divert them from other important work; on the other hand, any dispute within the community over editor presets and the like would sooner or later bubble up to DWG anyway. If a panel is created that is separate from DWG, we'd definitely have to build ourselves some safeguards that avoid finding the two bodies on different sides of a dispute ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for Software Dispute Resolution Panel
On Tuesday 04 August 2020, Dorothea Kazazi wrote: > > The OSMF board just published a proposal for a software > dispute resolution panel: > https://blog.openstreetmap.org/2020/08/04/proposal-for-software-dispu >te-resolution-panel/ I guess i am asking too much if i envision the board creating a panel it does not control itself... For context - the DWG, which is the traditional and broadly respected entity to resolve conflicts in mapping, is not controlled in composition by the board, it decides on accepting new members themselves. See also: https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Membership_Policy https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Conflict_of_Interest_Policy Significant parts of the authority the DWG has among mappers derive from the fact that it is not composed of political appointees. Interesting also that the composition of the panel is supposed to reflect "all interests of the OSM community" but competence of the panel members on the subject, experience with and knowledge of mapping and tagging in OSM or in other words: The competence to assess evidence on the cases they deal with and to deliberate on the matters in a qualified and knowledgable way, is not a criterion. Neither is impartiality on prominent special interests like those of corporate data users. Transparency is limited to the ultimate decisions being made public (indeed important, would be interesting how this would function otherwise). I guess that means both the nominations and selection of panel members as well as the deliberation and consulting of the panel on cases is going to happen behind closed doors. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
Indeed, this is exactly what I was thinking. From an engineering maintenance perspective, even if you managed to get something "working", the result would be an incomprehensible mess. I don't usually like to speak in such extremes, and I certainly don't mean any offense, but in this case it's warranted: this is a pretty bad idea. On Tue, 2020-08-04 at 14:08 -0400, Mike Nice wrote: > On 8/4/2020 7:21 AM, pangoSE wrote: > > I suggest we wait for ruffle to be ready and then compile P2 to > > first wasm and then decompile it into C and then translate it into > > rust. > > It can then be cleaned up and shipped to both as a desktop > > application and a wasm binary run in the browser. > ruffle -> wasm -> C -> rust is unlikely to be useful. Sure it might > run, but all program comments will have been stripped. The automatic > C > -> Rust step is likely to generate unsafe mode code that must be > cleaned > up to fully see the benefits of Rust. And finally, the result > would > not be maintainable over the long term without a huge amount of > cleanup. > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Proposal for Software Dispute Resolution Panel
Hello, The OSMF board just published a proposal for a software dispute resolution panel: https://blog.openstreetmap.org/2020/08/04/proposal-for-software-dispute-resolution-panel/ .. and is asking for comments and feedback. Please reply to this message ~ thank you. warm greetings, Dorothea ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
On 8/4/2020 7:21 AM, pangoSE wrote: I suggest we wait for ruffle to be ready and then compile P2 to first wasm and then decompile it into C and then translate it into rust. It can then be cleaned up and shipped to both as a desktop application and a wasm binary run in the browser. ruffle -> wasm -> C -> rust is unlikely to be useful. Sure it might run, but all program comments will have been stripped. The automatic C -> Rust step is likely to generate unsafe mode code that must be cleaned up to fully see the benefits of Rust. And finally, the result would not be maintainable over the long term without a huge amount of cleanup. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Mapping feature ideas (was: Funding of three infrastructure projects)
On 04/08/2020 11.08, Martin Koppenhoefer wrote: On 4. Aug 2020, at 16:26, Matthew Woehlke wrote Obviously, this would all almost surely be a temporary mode (maybe it persists as long as JOSM is open, but isn't uploaded), but since you usually draw once, that would be fine. (Bonus points if JOSM could automatically recreate constraints for ways that don't have any. It shouldn't be hard to guess equality, perpendicular and colinear constraints, at least.) rather than guessing, I sometimes have wished there had been a way to actually store relationships (geometric) in the data, something like these buildings all align their front facades, or this door (or building position) is aligned to this street axis, etc., so when people moved the street, the building would move as well. Would become very complex if it would be used extensively (basically you might move the whole city by moving a node, or it could lead to unresolvable constraints, etc.), so I think it’s not gonna come. Just accept some fuzziness ;-) Sure, I can see the use. I was thinking in terms of things that can be done without schema changes. Besides the troubles of trying to resolve an overconstrained system (something I've run into with FreeCAD for systems that are probably much more simple than what OSM might become!), another issue is that editors that don't support the constraints — I'm looking at iD, mostly because I shudder to think of the complexity and performance of implementing a solver in a web browser! — will tend to break them often. So, I'm not going to hold my breath ;-). People are overrating rectangular buildings anyway, they might look more correct than a freehand approximation, but they typically aren’t (too short, too long, too wide, wrong angle not parallel to the street, not parallel to their neighbors, etc.), sometimes resulting from misinterpretation of aerial imagery and conscious or unconscious generalization (representing with a single rectangle what in reality is a rectangle with an oriel or a cutting or some other added shape). Sure, I've seen some overly generalized buildings. I tend to model with more detail. (See for example https://www.openstreetmap.org/way/44931534, which is also a good example of where more constraints would have been useful; there are at least three axes of symmetry, and the four corners at the extrema of the longer axis *realy* look like they line up.) Still, we *do* tend to build things with right angles, so right angles are very often correct. At least for buildings. (Roads can easily get more sloppy.) And sometimes a lack of diligence (e.g. when a building is on the crossing of two roads which aren’t orthogonal, it is not unlikely that the building isn’t orthogonal either, and it might be easily visible in the imagery, but if you only have a hammer, you might be tempted to use it for the screws as well). Well, that's a user problem :-). I've also run into many, many instances of things that seem like they *ought* to line up, but if aligning is noticeably different from the imagery, I won't force it. Most of what I'm picky about is within individual buildings, or stuff like aligning parking aisles in the middle of the spaces because it renders better and the way is (since it's a line, not an area) necessarily an approximation anyway. Conversely, I'll get a little more "sloppy" with placement, because I generally trace roof lines and then try to shift the shape to compensate for parallax and my best guess at how much the roof overhangs the wall. Again, see the previously cited example and compare how it lines up with the corners *on the ground* and not the roof line. See the adjacent https://www.openstreetmap.org/way/830822584 for an even more pronounced example; this one is straddling separate images that were stitched together, so there is a discontinuity in the parallax going through the middle of it. Constraints actually *help* here because I can make a reasoned guess at stuff like "these walls probably line up" and use that to try to deduce the actual shape when the imagery is messed up. Of course, a lot of this will depend on the quality/resolution of the imagery available. On the US East Coast, MapBox is very high resolution, which help significantly. Trying to map to the level of detail I'm typically doing is probably not possible with lower resolution imagery. -- Matthew ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
Am 04.08.2020 um 17:05 schrieb Alexandre Oliveira: >> At this time nobody is proposing anything more than giving P2 a bit more >> life for a small sum of money > And as myself and others have brought up, it's not a good idea to > spend money to port P2 from a dead technology to another dead > technology, if people still use it it's much more beneficial in the > long term to port it to modern web technologies than have to spend a > few thousand bucks every once in a while to port a software that's > pretty important for OSM (even though its usage has decreased over the > years the changeset amount is still high) to another dead technology. The problem with that is that it implies 2 to 3 more zeros (at least) before the decimal point in the costs, and -then- the question really arises why we are doing that. Literally nobody including Richard has proposed to spend more money down the road, and given that he tends to be relatively down to earth I assume he is not expecting eternal support. > > As someone (I can't recall who it was) said, "$2500 is not much", then > if the OSMF wants to spend it on useless efforts (i.e. porting P2 from > Flash to Air) then why not give it to me then, if the OSMF wants to > spend this money? :P Jokes aside, if the OSMF really wants to spend > this money I'd suggest it to be spent somewhere else if the board is > so keen on setting up life support and going through the stress that > it is to maintain dead libraries. The reason is that the users want to continue to use P2 for now (see discussion in the forum for example). To put this in to perspective we are talking about a one time spend of about 1 € per head, somewhat less than what iD costs per year (every year), and at least an order of magnitude less than the same for JOSM etc. Simon signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
sent from a phone > On 4. Aug 2020, at 16:53, Simon Poole wrote: > > but it isn't a good measure of what the OSMF should spend its money on, weere > applying an 80/20 rule is likely to be far more appropriate. > As I have said, I’m fine with spending 2500 on a dead proprietary technology because some long term contributors rely on it and because it’s part of our legacy, but only because I’m not applying an 80/20 rule, but an 99/1 rule ;-) With an 80/20 approach it would not make sense because there are already a lot of alternative editing possibilities available. > . Definitely nobody is going to embark on the multi-million undertaking that > writing and bringing to production a new editor is > you are suggesting that the PL2 development is worth several millions of dollars/euros/pounds? Let’s remain serious. Several millions would be tens of man-years. Cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
sent from a phone > On 4. Aug 2020, at 16:26, Matthew Woehlke wrote > > Obviously, this would all almost surely be a temporary mode (maybe it > persists as long as JOSM is open, but isn't uploaded), but since you usually > draw once, that would be fine. (Bonus points if JOSM could automatically > recreate constraints for ways that don't have any. It shouldn't be hard to > guess equality, perpendicular and colinear constraints, at least.) rather than guessing, I sometimes have wished there had been a way to actually store relationships (geometric) in the data, something like these buildings all align their front facades, or this door (or building position) is aligned to this street axis, etc., so when people moved the street, the building would move as well. Would become very complex if it would be used extensively (basically you might move the whole city by moving a node, or it could lead to unresolvable constraints, etc.), so I think it’s not gonna come. Just accept some fuzziness ;-) People are overrating rectangular buildings anyway, they might look more correct than a freehand approximation, but they typically aren’t (too short, too long, too wide, wrong angle not parallel to the street, not parallel to their neighbors, etc.), sometimes resulting from misinterpretation of aerial imagery and conscious or unconscious generalization (representing with a single rectangle what in reality is a rectangle with an oriel or a cutting or some other added shape). And sometimes a lack of diligence (e.g. when a building is on the crossing of two roads which aren’t orthogonal, it is not unlikely that the building isn’t orthogonal either, and it might be easily visible in the imagery, but if you only have a hammer, you might be tempted to use it for the screws as well). Cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
> At this time nobody is proposing anything more than giving P2 a bit more life > for a small sum of money And as myself and others have brought up, it's not a good idea to spend money to port P2 from a dead technology to another dead technology, if people still use it it's much more beneficial in the long term to port it to modern web technologies than have to spend a few thousand bucks every once in a while to port a software that's pretty important for OSM (even though its usage has decreased over the years the changeset amount is still high) to another dead technology. As someone (I can't recall who it was) said, "$2500 is not much", then if the OSMF wants to spend it on useless efforts (i.e. porting P2 from Flash to Air) then why not give it to me then, if the OSMF wants to spend this money? :P Jokes aside, if the OSMF really wants to spend this money I'd suggest it to be spent somewhere else if the board is so keen on setting up life support and going through the stress that it is to maintain dead libraries. -- Atenciosamente, Alexandre Oliveira. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
Could we move all the programming language du jour fanboying, apps that have nothing to do OSM and other unrelated to the topic discussions somewhere else please? And yes it underlines my point that regardless of how exotic the feature is, you are always going to find somebody that finds it critical to success (this one of the reasons why JOSM has three variants of everything), but it isn't a good measure of what the OSMF should spend its money on, weere applying an 80/20 rule is likely to be far more appropriate. At this time nobody is proposing anything more than giving P2 a bit more life for a small sum of money, if Richard has a plan for longer term maintenance and development then that should be considered when proposed. Definitely nobody is going to embark on the multi-million undertaking that writing and bringing to production a new editor is, just on the base that it would be cool to write one in . Simon Am 04.08.2020 um 16:26 schrieb Matthew Woehlke: > On 04/08/2020 08.10, Martin Koppenhoefer wrote: >> On 4. Aug 2020, at 13:58, Matthew Woehlke wrote: >>> but I would practically *kill* for JOSM to have FreeCAD's suite of >>> sketch constraints ;-). >> >> you’re aware that there are sketch constraints for configurable >> angles (90, 60, 45 etc) and projection snaps? Hit 2 times „a“ (angle >> display becomes green) > Yes. They're better than nothing, but nowhere near what I'm talking > about. As an example, consider the attached simple FreeCAD sketch > which is roughly representative of some buildings I've mapped > recently. The dome in front is centered (segments on either side > constrained to be equal). The "wings" in back are symmetrical. > > It's *possible* to do this sort of thing in JOSM with a lot of care > and by building part of the geometry, then constructing a bunch of > "scratch" geometry in order to construct a symmetry line, then doing a > copy, paste in place, mirror, reverse, stitch the parts together... > but God help you if you make a mistake and have to start over. > > In FreeCAD, you just slap on some equality constraints, angle > constraints, parallel constraints, etc. and then you can *move* any of > the nodes and everything else will update to preserve the applied > constraints. (The one things it's missing that would be helpful is a > *colinear* constraint; you have to simulate that with parallel and > coincident constraints using "construction" lines; those are the blue > ones. A colinear constraint could eliminate the need for those > construction lines.) This is the major difference, though. In JOSM, > constraints only apply when you initially draw something, so if you > get it wrong, you have to start over. In FreeCAD, they're a dynamic > system; if you get it wrong, just nudge it and the whole thing updates > *while preserving your constraints*. > > Oh, and *arcs*. The ability to define a segment that should be a > perfect arc, and optionally make it tangent or perpendicular to its > neighbors, would be a major boon. Again, I can fake it with a bunch of > scratch construction, but if it's wrong, I have to start over and hope > my next guess is better. In FreeCAD, just drag the end points until it > looks right. > > Then there are distance constraints, which would be incredibly useful > if you're mapping something with known dimensions. > > Seriously, give FreeCAD a spin. It's pretty awesome for this sort of > relatively simple 2D stuff. Also look at some of the buildings I've > done recently; the symmetrical ones don't just *look* symmetrical, > they *are* symmetrical (within the limits of JOSM's abilities). I've > also done a lot of stuff like roads that are perfectly centered in > between parking spaces, groups of aligned buildings that are > *actually* aligned, and whatnot. It's do-able, but it would be *s* > much easier with FreeCAD-style constraints. > > Obviously, this would all almost surely be a temporary mode (maybe it > persists as long as JOSM is open, but isn't uploaded), but since you > usually draw once, that would be fine. (Bonus points if JOSM could > automatically recreate constraints for ways that don't have any. It > shouldn't be hard to guess equality, perpendicular and colinear > constraints, at least.) > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
On 04/08/2020 08.10, Martin Koppenhoefer wrote: On 4. Aug 2020, at 13:58, Matthew Woehlke wrote: but I would practically *kill* for JOSM to have FreeCAD's suite of sketch constraints ;-). you’re aware that there are sketch constraints for configurable angles (90, 60, 45 etc) and projection snaps? Hit 2 times „a“ (angle display becomes green) Yes. They're better than nothing, but nowhere near what I'm talking about. As an example, consider the attached simple FreeCAD sketch which is roughly representative of some buildings I've mapped recently. The dome in front is centered (segments on either side constrained to be equal). The "wings" in back are symmetrical. It's *possible* to do this sort of thing in JOSM with a lot of care and by building part of the geometry, then constructing a bunch of "scratch" geometry in order to construct a symmetry line, then doing a copy, paste in place, mirror, reverse, stitch the parts together... but God help you if you make a mistake and have to start over. In FreeCAD, you just slap on some equality constraints, angle constraints, parallel constraints, etc. and then you can *move* any of the nodes and everything else will update to preserve the applied constraints. (The one things it's missing that would be helpful is a *colinear* constraint; you have to simulate that with parallel and coincident constraints using "construction" lines; those are the blue ones. A colinear constraint could eliminate the need for those construction lines.) This is the major difference, though. In JOSM, constraints only apply when you initially draw something, so if you get it wrong, you have to start over. In FreeCAD, they're a dynamic system; if you get it wrong, just nudge it and the whole thing updates *while preserving your constraints*. Oh, and *arcs*. The ability to define a segment that should be a perfect arc, and optionally make it tangent or perpendicular to its neighbors, would be a major boon. Again, I can fake it with a bunch of scratch construction, but if it's wrong, I have to start over and hope my next guess is better. In FreeCAD, just drag the end points until it looks right. Then there are distance constraints, which would be incredibly useful if you're mapping something with known dimensions. Seriously, give FreeCAD a spin. It's pretty awesome for this sort of relatively simple 2D stuff. Also look at some of the buildings I've done recently; the symmetrical ones don't just *look* symmetrical, they *are* symmetrical (within the limits of JOSM's abilities). I've also done a lot of stuff like roads that are perfectly centered in between parking spaces, groups of aligned buildings that are *actually* aligned, and whatnot. It's do-able, but it would be *s* much easier with FreeCAD-style constraints. Obviously, this would all almost surely be a temporary mode (maybe it persists as long as JOSM is open, but isn't uploaded), but since you usually draw once, that would be fine. (Bonus points if JOSM could automatically recreate constraints for ways that don't have any. It shouldn't be hard to guess equality, perpendicular and colinear constraints, at least.) -- Matthew ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Celebrate OSM birthday on 2020-08-08
Hi all, I haven't seen OSM's birthday mentioned yet here this year: mark your calendars https://blog.openstreetmap.org/2020/08/01/celebrate-the-16th-osm-anniversary/ -jeff -- Jeff McKenna MapServer Consulting and Training Services co-founder of FOSS4G http://gatewaygeo.com/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
We should not ask anyone to do 2 months development work for 2500 euros. I believe this size grant is only enough for 1 to 2 weeks, based on international prices (though I do not have any paid experience in this field) - Joseph Eisenberg On Tue, Aug 4, 2020 at 4:08 AM pangoSE wrote: > I disagree. For that sum of money I would be willing to start writing a > new editor in Rust compiled to WebAssembly and desktop and reach a state of > basic editing useability in 2 months. > See also https://www.youtube.com/watch?v=ohuTy8MmbLc > Cheers > > Joseph Eisenberg skrev: (3 augusti 2020 > 01:00:49 CEST) > >> While the benefit of making Potlatch 2 on AIR is small, the cost is tiny. >> >> 2500 Euros is an insignificant price to pay for supporting an editor >> which is still used by a couple of thousand long-term users. >> >> I support this expenditure. >> >> – Joseph Eisenberg >> >> On Sun, Aug 2, 2020 at 10:05 AM Alexandre Oliveira >> wrote: >> >>> I'd like to share my two cents on the matter of supporting Potlatch 2, >>> an editor built with (now) dead technology. >>> >>> I don't think it's worth spending money to update P2 to Air. As others >>> have stated, Air has been discontinued as well, and it was developed >>> by Adobe, probably with the same amount of security flaws as Flash >>> had, which contributed to its demise. I don't see Air as different >>> even though it's being maintained now by Samsung. >>> >>> Just take a look. The web is different than when P2 released; flash is >>> deprecated and a synonym for vulnerable systems, Air tried to take off >>> but now it's just another dead technology. What are the benefits of >>> porting P2 to Air? It may be easier because Air may share some code >>> with Flash, which in turn makes it easier to port to. >>> >>> However, I think that the OSMF should find someone familiar with Flash >>> and look forward to porting P2 to modern web technologies (please not >>> Electron!), like WebAssembly or Web 2.0. Be it JavaScript, >>> CoffeeScript or TypeScript, React, Angular, Vue.js or any other modern >>> web tech, it doesn't matter. I think it's going to be money well spent >>> if P2 was ported to a supported web technology and not something that >>> died a few years ago and is on life support, and barely anyone uses it >>> nowadays. >>> >>> IMO porting P2 to Air is just a waste of money and time from the >>> developer, and we will reach the same point in the future, be it >>> either for deprecating P2 or looking to port it to newer web >>> technologies. OSMF should prepare for the future and not continue >>> using deprecated technology. >>> >>> ___ >>> talk mailing list >>> talk@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk >>> >> ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
sent from a phone > On 4. Aug 2020, at 13:58, Matthew Woehlke wrote: > > but I would practically *kill* for JOSM to have FreeCAD's suite of sketch > constraints ;-). you’re aware that there are sketch constraints for configurable angles (90, 60, 45 etc) and projection snaps? Hit 2 times „a“ (angle display becomes green) Cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
On 04/08/2020 05.30, pangoSE wrote: On older hardware like my 2 core 2ghz laptop iD is slow. Loading while saving an edit is slow, while JOSM is always fast and saving does not close the edit view so you can continue without waiting for a browser to load the iD editor again which is also slow. I want your JVM :-). I have yet to encounter a Java program (including JOSM) that isn't sluggish. (JOSM could be worse, but it's nowhere near what I'd expect from a well-written *native* application.) Matthew Woehlke skrev: (3 augusti 2020 16:14:13 CEST) (¹ iD can 'square up' individual nodes and does a passable job with *mostly* orthogonal shapes with the odd 45° angle. There are ways to work with those in JOSM, but generally speaking if you try to square a shape with a single 'wild' node, JOSM turns the whole thing into a hot mess.) This sounds like a bug. Have you reported it? Ah... I partially retract that. I think the problem is that I'm trying to make it work more like iD which permits *selective* squaring. I probably have some nodes selected that's making it go bonkers. Really, this is a missing feature; I want a way to either square up individual nodes, or only angles that are within some delta of 90° already (and maybe to snap other angles to e.g. 45°). Meanwhile, I've gotten better at creating scratch geometry to help with construction, but I would practically *kill* for JOSM to have FreeCAD's suite of sketch constraints ;-). -- Matthew ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
Martin Koppenhoefer skrev: (3 augusti 2020 01:10:09 CEST) > > >sent from a phone > >> On 2. Aug 2020, at 18:11, Guillaume Rischard > wrote: >> >> As someone who’s listed as having used 9 different editors on >https://hdyc.neis-one.org/?Stereo (including “unknown”), I know how >important the variety and richness of editing possibilities is. > > >agreed. Admittedly the stats look pretty bad, user numbers have been >dropping constantly since 2012, in 2015 there were 24000 PL2 users, >2016: 14700, 2017 1, 2018 6400, 2019 4900 and 2020 only 2500 so >far, but I am willing to believe that these are mostly long term and >hardcore contributors, and 2500 is no big money for the >OpenStreetMap-Foundation, so it may be worth the effort. At least you >can be sure that in these 9,7 million edits no imports are hiding ;-) >and this number makes it 4th for performed edits. > >Cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
mmd skrev: (2 augusti 2020 11:31:21 CEST) >On 2020-08-01 12:42, Richard Fairhurst wrote: >> Ruffle is showing promise (https://github.com/ruffle-rs/ruffle) and >is >> under very active development, but does not yet support AS3 or the >Flash >> Player features that P2 needs. I would anticipate that P2 will be >able >> to run as WebAssembly when Ruffle reaches feature parity with AIR >2.6. > >Yes, exactly, that's one of the two approaches I had in mind: rewriting >from scratch preferably also in Rust (which obviously wouldn't fit in >the proposed budget or timeframe), or use Ruffle with the existing >code. > I suggest we wait for ruffle to be ready and then compile P2 to first wasm and then decompile it into C and then translate it into rust. It can then be cleaned up and shipped to both as a desktop application and a wasm binary run in the browser. See https://github.com/wwwg/wasmdec https://github.com/jameysharp/corrode ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
sent from a phone > On 4. Aug 2020, at 12:28, Andy Townsend wrote: > > I wrote down what I was there, other people's GPS traces, etc. etc.) and that > really needs a desktop editor. +1, while mobile editors are a great addition to our toolset, they cannot substitute desktop editors. A mouse is still much faster and more precise than touch input, i.e. for those types of edits where you add or modify a lot of geometry, or copy paste information from various sources. Cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
I disagree. For that sum of money I would be willing to start writing a new editor in Rust compiled to WebAssembly and desktop and reach a state of basic editing useability in 2 months. See also https://www.youtube.com/watch?v=ohuTy8MmbLc Cheers Joseph Eisenberg skrev: (3 augusti 2020 01:00:49 CEST) >While the benefit of making Potlatch 2 on AIR is small, the cost is >tiny. > >2500 Euros is an insignificant price to pay for supporting an editor >which >is still used by a couple of thousand long-term users. > >I support this expenditure. > >– Joseph Eisenberg > >On Sun, Aug 2, 2020 at 10:05 AM Alexandre Oliveira > >wrote: > >> I'd like to share my two cents on the matter of supporting Potlatch >2, >> an editor built with (now) dead technology. >> >> I don't think it's worth spending money to update P2 to Air. As >others >> have stated, Air has been discontinued as well, and it was developed >> by Adobe, probably with the same amount of security flaws as Flash >> had, which contributed to its demise. I don't see Air as different >> even though it's being maintained now by Samsung. >> >> Just take a look. The web is different than when P2 released; flash >is >> deprecated and a synonym for vulnerable systems, Air tried to take >off >> but now it's just another dead technology. What are the benefits of >> porting P2 to Air? It may be easier because Air may share some code >> with Flash, which in turn makes it easier to port to. >> >> However, I think that the OSMF should find someone familiar with >Flash >> and look forward to porting P2 to modern web technologies (please not >> Electron!), like WebAssembly or Web 2.0. Be it JavaScript, >> CoffeeScript or TypeScript, React, Angular, Vue.js or any other >modern >> web tech, it doesn't matter. I think it's going to be money well >spent >> if P2 was ported to a supported web technology and not something that >> died a few years ago and is on life support, and barely anyone uses >it >> nowadays. >> >> IMO porting P2 to Air is just a waste of money and time from the >> developer, and we will reach the same point in the future, be it >> either for deprecating P2 or looking to port it to newer web >> technologies. OSMF should prepare for the future and not continue >> using deprecated technology. >> >> ___ >> talk mailing list >> talk@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk >> ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
On 04/08/2020 11:19, pangoSE wrote: I would recommend you to use another way to archive this. Open OsmAnd on your phone and add a POI directly. You can add tags too if you remember them. Then upload directly to OSM. No JOSM or GPX file handling neccesary. I use Vespucci for exactly that (no, I'm not on commission - other mobile editors are available!) but often you need to take information from all sorts of different sources (imagery, my GPS information, what I wrote down what I was there, other people's GPS traces, etc. etc.) and that really needs a desktop editor. Best Regards, Andy ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Suggestions welcome | Re: Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
> In the absence of other proposals, even splitting it among the other two > would be a much better use, in my opinion. Chrm. iD gets the pile of money and the MAIN OpenStreetMap editor - JOSM - gets NOTHING? Or does this show that iD is so broken/unwanted that nobody wants to work on it without getting paid a lot? -- Tomas ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
I would recommend you to use another way to archive this. Open OsmAnd on your phone and add a POI directly. You can add tags too if you remember them. Then upload directly to OSM. No JOSM or GPX file handling neccesary. Andy Townsend skrev: (3 augusti 2020 00:09:44 CEST) >On 02/08/2020 22:52, Martin Koppenhoefer wrote: >> >> >> sent from a phone >> >>> On 2. Aug 2020, at 17:09, Andy Townsend wrote: >>> >>> GPX track waypoint handling is the biggest missing piece of >>> functionality for me, so you can start with that one if you wish >> >> >> I guess this is about not handling symbols? > >Not really - see >https://help.openstreetmap.org/questions/6368/in-josm-is-it-possible-to-see-gpx-track-waypoint-details > >for information. > >If there's a better answer available now (which is entirely possible - >I >asked that question 9 years ago!) then I'd suggest adding it at that >help question. See also >https://help.openstreetmap.org/questions/7675/josm-is-it-possible-to-convert-an-individual-waypoint-in-a-gpx-file-to-a-node > >which is somewhat similar. > >Best Regards, > >Andy > > > >___ >talk mailing list >talk@openstreetmap.org >https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
I agree with this. Particularly Rust compiled to WebAssembly look very promising for building applications like an editor. Rust is fast and safe and it already has multiple OSM related crates. See here for an example: https://www.youtube.com/watch?v=YHJjmsw_Sx0 An editor written in Rust and compiled to WebAssembly would probably be a lot faster than iD is today. Writing something completely in browser JS these days is not the best way forward if speed and portability is is important iMO. Alexandre Oliveira skrev: (2 augusti 2020 19:01:23 CEST) >I'd like to share my two cents on the matter of supporting Potlatch 2, >an editor built with (now) dead technology. > >I don't think it's worth spending money to update P2 to Air. As others >have stated, Air has been discontinued as well, and it was developed >by Adobe, probably with the same amount of security flaws as Flash >had, which contributed to its demise. I don't see Air as different >even though it's being maintained now by Samsung. > >Just take a look. The web is different than when P2 released; flash is >deprecated and a synonym for vulnerable systems, Air tried to take off >but now it's just another dead technology. What are the benefits of >porting P2 to Air? It may be easier because Air may share some code >with Flash, which in turn makes it easier to port to. > >However, I think that the OSMF should find someone familiar with Flash >and look forward to porting P2 to modern web technologies (please not >Electron!), like WebAssembly or Web 2.0. Be it JavaScript, >CoffeeScript or TypeScript, React, Angular, Vue.js or any other modern >web tech, it doesn't matter. I think it's going to be money well spent >if P2 was ported to a supported web technology and not something that >died a few years ago and is on life support, and barely anyone uses it >nowadays. > >IMO porting P2 to Air is just a waste of money and time from the >developer, and we will reach the same point in the future, be it >either for deprecating P2 or looking to port it to newer web >technologies. OSMF should prepare for the future and not continue >using deprecated technology. > >___ >talk mailing list >talk@openstreetmap.org >https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
Hi Matthew Woehlke skrev: (3 augusti 2020 16:14:13 CEST) >On 02/08/2020 06.05, Simon Poole wrote: > >I'm not saying iD is *bad*. It's a very nice editor *for its >capabilities*. It's great for making *small* changes or introducing >someone to OSM editing... but there are a lot of use cases still where >JOSM is just a far superior tool. Maybe in *5-10* years that will >change, but I'm not going to hold my breath on it overtaking JOSM in >1-2. On older hardware like my 2 core 2ghz laptop iD is slow. Loading while saving an edit is slow, while JOSM is always fast and saving does not close the edit view so you can continue without waiting for a browser to load the iD editor again which is also slow. > >(¹ iD can 'square up' individual nodes and does a passable job with >*mostly* orthogonal shapes with the odd 45° angle. There are ways to >work with those in JOSM, but generally speaking if you try to square a >shape with a single 'wild' node, JOSM turns the whole thing into a hot >mess.) This sounds like a bug. Have you reported it? Cheers pangoSE ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Suggestions welcome | Re: Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
I agree. Skyler Hawthorne skrev: (2 augusti 2020 19:30:09 CEST) >In the absence of other proposals, even splitting it among the other >two would be a much better use, in my opinion. > >-- >Skyler > > >On Sun, Aug 2, 2020, at 13:27, Rory McCann wrote: >> On 02.08.20 01:03, Skyler Hawthorne wrote: >> > Sorry if this sounds harsh, but I think using any funds at all to >> > continue support for a tool that 1% of editors use would be >wasteful. >> > Flash is, for all intents and purposes, a dead technology. This >money is >> > better spent on other uses. >> >> What would you suggest? >> >> Serious question. We're suggesting spending €2,500 on this. Where >else >> do you suggest spending €2,500 on? >> >> Rory >> ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
