Labi, var noņemt cycleway birkas no ceļiem, kuriem blakus ir uzzīmēta atsevišķa velojosla. Bet tehniski, tā ir tikai un vienīgi Cycle Map renderētāja vaina. Dati kā tādi nav nepareizi.

Vai kaut kas salūzīs, ja veloceļi tiks zīmēti atsevišķi?

"cycleway=lane" ir pareizi, velojoslas joprojām neatdala fiziskas barjeras no ceļa. No dažām līnijām noņēmu, jo domāju, ka nav jēgas atstāt, ja es zīmēju atsevišķu veloceļa līniju, bet vēlāk sapratu, ka varēja atstāt, jo tehniski bija taču pareizi, bet slinkums bija atlikt atpakaļ.

Visparīgi, man nepatīk ņemties ar neskaitāmām birkām pie galvenā ceļa, es labāk visus ceļus zīmēju atsevišķi. Tad ir pārskatāmi, kartē renderējas un nav jāņemas ar birku haosu.

@arcth I really recommend you to check out the group chat @richlv posted. We can continue this discussion there. Another mapper made a really good point (that's as good as reply I would give) about this topic so advise you to read it: https://osmlatvija.zulipchat.com/#narrow/channel/358602-general/topic/rel.C4.81ciju.20lieto.C5.A1ana/near/500852509

Takas nekur nav pazudušas, ir tikai žogs aplikts apkārt! Pats apstaigāju šo vietu klātienē. Un kad reiz sāksiet izskaidrojošy izmaiņu komentārus rakstīt?

Pārsvarā esat veicis aplamus labojumus. Tramvaja sliedes vēl nav nekur sākts būvēt, joprojām proposed. Būvdarbi nenotiek teritorijās, kur nomainījat uz būvdarbiem. Pats dzīvē apstaigāju šīs vietas.

This edit directly duplicated many buildings and had to reverted to save my and other mappers' time. Please don't duplicate buildings.

All your recent edits had created duplicate features like buildings and lakes directly on top of existing features. I reverted these edits. Please don't create duplicate features.

Atliku atpakaļ "name" vērtību pagaidām. Ja izmaiņas autors vēlēsies turpināt šo diskusiju, tad redzēs vai būs kaut kas jāmaina.

I just want to point out that the provided mapillary footage is outdated. Here's a new one from July 2024: https://www.mapillary.com/app/?lat=54.6729267&lng=25.2726497&z=19.9&pKey=880819717313713&focus=photo&x=0.08102023366484773&y=0.6206059317455411&zoom=0.8075370121130552

And in this region NŽT ORT10LT is outdated too. Bing here is much higher quality and more up to date. The separation between main street and cycleway is clearly visible in both Bing aerial imagery and mapillary footage.

Instead of "not:brand:wikidata" you should add the "operator:wikidata" tag which is Q132157239 in this case.

"Did you try to find out why was the landuse mapped this way before declaring multipolygons useless and mass-converting them?"

That's one the reason why I started this discussion and my theory that you find it easier to edit with mps was confirmed.

This method might be an easier one for you but don't you understand that other editors find it very hard to edit the section in the map you were editing after you, especially iD users? iD editor is quite restrictive, it will straight up prevent user from doing actions that may or may not cause errors, like disconnecting members of a mp or performing actions on an element if it's not entirely visible. That's annoying, but iD is intuitive and modern, interface is visually appealing. That's why I use iD for mainly simple tasks. But randomly comming across areas mapped like multipolygons which I want to edit always makes me sigh and open JOSM to deal with them and then return to iD to finish what I started.

I don't know if there are but from my own experience I know that area borders divided into countless multipolygons make mapping extremely hard, especially for casual mappers who are not into advanced stuff like multipolygons. Other mappers have expressed frustration with this as well. And this can and will confuse new mappers who don't know anything about multipolygons and will be scared to touch them.

The main problem I have with this edit is that you restored multipolygons in first two locations I mentioned without changing almost anything else. Walls and fences around Ziedoņdārzs and Ivana kapi areas could have been easily added without recreating mps. You changed much more around south of Daugavas stadions so I don't have any particular complaints about those changes.

Again, if using this mp technique makes mapping easier, then keep using it. Just don't convert simple polygons to mps without any reason at all like you did in the first two locations.

You recreated multipolygons around Ivana kapi, aroudn Ziedoņdārzs and in areas south of Daugavas Stadions. The only useful changes done by you are at the third location.

What was the reason for it? They have no reason to exist! These elements can exist as simple polygons without problems!

I understand it might be easier to create areas which connect to each other using the multipolygon method. But I don't see a reason to restore multipolygons if you are not going to change anything there or if you're going to just move a few nodes around!

Fixing this edit without reverting your good edits seems very hard if not impossible. I might have to revert the entire change set if I'm not able to find a reliable way to fix this.

Izlaboju pats, jo, šķiet, nelasat izmaiņu komentārus.

Kāpēc skolas teritorija[1] tika pārvērsta par vārdā nenosauktu social_facility, bet skolas dati atstāti uz ēkas[2]?

[1] way/1092749083
[2] way/87825719

Smiltis ir daļa no spēļlaukuma, tāpēc šiem abiem elementiem nevajadzētu būt multipoligonā.

Es salaboju biedru lomas šajās relācijās: changeset/162433199

Izmaiņu vēsturē gan neparādīsies.

Do you think it is correct to change building names to versions you proposed? There are two companies operating in Latvia: Rimi Baltic and Rimi Latvia. Which one is operating here? If not clear, we could drop "Baltic" and simply name this surrounding commercial area "Rimi".

Generally, the name of the territory is added in the "name" tag of the surrounding land use element; otherwise, if there isn't a name, then the name of the company operating the territory is added. But, no matter what, each case should be evaluated individually. In this case, if it is not clear which company is operating in this territory, I would simply name it "Rimi".

I understand the problem with navigators routing through private access roads. That is something to be concerned about, and it indeed can confuse people. But the problems with how routers are programmed aren't the reason to change actual map data. The map should be as accurate as possible.

OSRM seems the most reliable routing solution. It avoids routing through roads marked with the "access=private" tag. Valhalla and GraphHopper ignore "access=private" values, but all three ignore roads with "access=no". Today another mapper changed access values for roads in Rimi territory. So, after a few weeks, OSRM should start routing accordingly.

Abās šajā izmaiņu kopā izveidotajās relācijās biedru lomas ir saliktas otrādāk. Šajos gadījumos "inner" vajag pārvērst
uz "outer" un "outer" uz "inner".

Jāņem vērā, ka multipoligona ārējai līnijai vienmēr jābūt "outer" lomā un elementam, kas ir iekšā, jābūt "inner" lomā.

Šajā[1] relācijā šai[2] līnijai jābūt "outer" nevis "inner" lomā. Un pārējiem diviem biedriem[3][4] jābūt "inner" nevis "outer" lomā. Tāpat arī otrā izveidotajā relācijā.

[1] relation/18690530
[2] way/1359072008
[3] way/216737542
[4] way/1359072009

Iekomentējāt pats savā izmaiņu kopā...