Các mục Legend nên là số ít hoặc số nhiều?


12

Trong một huyền thoại bản đồ nên các mục là số ít hoặc số nhiều? Cái gì đúng? Đường hay đường?

Một tìm kiếm hình ảnh của Google cho "huyền thoại bản đồ" khiến tôi kết luận rằng không có cách nhất quán để có một mục chú thích là số ít hoặc số nhiều. Các bản đồ có thẩm quyền hơn mà tôi đã thấy có các mục huyền thoại ở số ít. (USGS, National Geographic, v.v.)

Vì vậy, câu hỏi của tôi là, trong trường hợp nào là một mục huyền thoại số nhiều đúng?

Hướng dẫn này nói số ít: http://gisgeography.com/map-elements-how-to-guide-map-making/ mục 32: Các tính năng trong Truyền thuyết là Hiện tại và Số ít

Ví dụ về một huyền thoại với các mục số ít và số nhiều mà tôi đã thực hiện. Huyền thoại - Mục số ít và mục số nhiều


1
Tôi nghi ngờ đó là vấn đề quan điểm và bất cứ ai chỉ định một bản đồ cụ thể. Tôi thích số nhiều trừ khi chỉ có một tính năng trong danh mục đó, ví dụ Khu vực nghiên cứu.
PolyGeo

Tôi không nghĩ nó hoàn toàn dựa trên ý kiến, có vẻ như người vẽ bản đồ cần phải hô vang ở đây vì có những lý do tôi nghe thấy hợp lệ nhưng tôi không thể nhớ đủ cả hai lý do để trả lời = P Hãy xem xét rằng Truyền thuyết mô tả những gì trong truyền thuyết và những vật phẩm đó là số ít (bạn thấy một biểu tượng luồng đơn), nhưng trên bản đồ, người xem sẽ thấy nhiều luồng. Một cuộc thảo luận khác mà tôi thấy thú vị là tại sao loại trừ tiêu đề "Truyền thuyết" khỏi một huyền thoại ... <mặc dù chủ đề riêng biệt!
SaultDon

Tôi đã dành vài giờ để tìm kiếm trên Google và trên ESRI Geonet nhưng tôi không thể tìm thấy bất cứ điều gì dứt khoát. Chỉ cần mục tôi liên kết trong câu hỏi ban đầu của tôi. Tôi nhớ lại đã thấy một cái gì đó trên Geonet trước đây, nhưng bây giờ tôi không thể tìm thấy nó. Tôi vừa đăng câu hỏi này trên GeoNet. geonet.esri.com/message/ trộm
Mattropolis

Tôi đã hỏi Aileen Buckley ESRI Cartogographics về vấn đề này. Cô ấy nghĩ rằng đó là một câu hỏi hay, và cô ấy đã viết một bài đăng trên blog về chủ đề của anh ấy trên Blog ArcGIS goo.gl/WtmuYC Câu hỏi này có thể được mở lại không?
Mattlands

Câu hỏi của bạn được mở lại. Cảm ơn đã theo dõi với Aileen.
PolyGeo

Câu trả lời:


8

Tôi đã hỏi Tiến sĩ Aileen Buckley, Người vẽ bản đồ Esri cho lời khuyên của cô ấy. Cô ấy đã viết một bài đăng trên blog giải thích khi nào bạn nên sử dụng số ít và số nhiều cho các mục huyền thoại. Tôi hỏi, có phải có một quy ước hoặc hướng dẫn bản đồ cho các nhãn vật phẩm huyền thoại là số ít hay số nhiều không? Các nhãn số nhiều có ngụ ý gì khác nhau không nếu có cả số ít và số nhiều?

Tóm tắt;

"Theo quy định, nhãn mục huyền thoại phải là danh từ số ít." ...

Ngoài ra, nhãn Do số nhiều có ngụ ý gì khác không?

Vâng, họ làm. Cách giải thích phổ biến nhất của các nhãn vật phẩm huyền thoại là số nhiều là có nhiều thứ cùng loại ở một vị trí . "

Blog ArcGIS đăng "Nhãn vật phẩm huyền thoại - số ít hoặc số nhiều" https://bloss.esri.com/esri/arcgis/2016/08/29/legend-item-labels-singular-or-plural/

Từ bài đăng của cô ấy, hình ảnh này cho thấy nơi bạn nên có các mục huyền thoại số nhiều. Một biểu tượng phòng vệ sinh ngụ ý nhiều phòng vệ sinh.

nhập mô tả hình ảnh ở đây


3

Đâ là một câu hỏi tuyệt vời. Tôi đồng ý rằng không có tiêu chuẩn cho các mục huyền thoại số nhiều. Thông thường, tôi sẽ sử dụng hình thức số ít, nhưng thường tôi sẽ làm cho nó số nhiều. Trong bản đồ của bạn, bạn chỉ có thể có một người nước được hiển thị. Vì vậy, sẽ không có ý nghĩa gì khi gọi nó là "Waterbody". Tuy nhiên, tôi không nghĩ nó tạo ra sự khác biệt lớn, nhưng tôi cho rằng, giống như bất cứ điều gì, nó phụ thuộc vào khán giả của bạn.

Cuối cùng, những gì tôi đưa vào truyền thuyết của mình là những gì khách hàng của tôi muốn.

Gần đây tôi đã thực hiện một loạt bản đồ và văn bản huyền thoại nằm trong Trường hợp Tiêu đề, đó là những gì tôi thường sử dụng. Tuy nhiên, khách hàng yêu cầu chỉ nên viết hoa từ đầu tiên. Khi họ đang trả tiền cho các bản đồ, tôi là ai để tranh luận?

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.